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1. Introduction 



Program synthesis is the task of automatically constructing a computer pro- 
gram from a description of the problem it is intended to solve. Although the 
prospect of a program synthesis system replacing human programmers is a long way 
off there are several near-term benefits to research on such systems. First, a 
program synthesis system requires considerable amounts of knowledge about pro- 
gramming and about the reasoning processes involved in synthesis. Before con- 
structing such a system we are forced to formalize our knowledge, seeking a 
degree of explicitness not normally required by human programmers. This process 
can lead to deep insights into aspects of programming which were only loosely 
organized and intuitively understood previously. Properly formulated, such 
knowledge can contribute to a science of programming useful both to human pro- 
grammers and automated programming systems. Second, as aspects of the program- 
ming task become better understood, it is natural to mechanize them, making it 
easier for human programmers to do their job. Thus, we expect to see special- 
purpose program synthesizers and programming aids become available long before 
the advent of general-purpose synthesizers. 

In this paper we outline a program synthesis system and provide in detail 
some of the knowledge about programming required by such a system. Our basic 
approach to program synthesis is a form of top-down design - a technique well- 
known in software engineering circles but not previously formalized to the 
extent that it could be automated. Top-down design works as follows: given a 
description of a problem we decompose it into descriptions of subproblems in 
such a way that solutions for the subproblems can be assembled into a solution 
for the original problem. We then apply top-down design to each of the subprob- 
lem descriptions. The decomposition process terminates in primitive problem 
descriptions which are solved directly, without decomposition into subproblems. 
A solution to the original problem is then formed by composing solutions to sub- 
problems according to the structure of the subproblem hierarchy. 

Cne of the principal difficulties in top-down design is knowing how to 
decompose a problem into subproblems. At present general knowledge of tins kind 
(see for example [18]) is intuitive and not in a form suitable for automation. 
Rather than attempt to formalize this general knowledge we focus on special ways 
to decompose a problem. In particular we present a theory concerning the struc- 
ture of divide and conquer algorithms and show how to decompose a problem with 
respect to that structure. 
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The principle underlying divide and conquer algorithms can be simply 
stated: if the problem posed by a given input is sufficiently simple we solve it 
directly, otherwise we decompose it into subproblems, solve the subproblems, 
then compose the resulting solutions. The process of decomposing the input prob- 
lem and solving the subproblems gives rise to the term "divide and conquer" 
although "decompose, solve and compose" would be more accurate. Che form of 
divide and conquer is expressed in an ad-hoc language in Figure 1 . We actually 
employ a more general schema in this paper. 

The reader will notice that the divide and conquer principle and top-down 
design are similar in nature. Both rely on a collection of operators for decom- 
posing problems into subproblems. These operators may work on some problems but 
not on others. In top-down design processes we often lack knowledge about 
which, if any, of the alternative operators will work on a given problem, so we 
must try each operator in turn; that is, we search. Divide and conquer algo- 
rithms, in contrast, have an inexpensive test to determine which operator 
applies to a given problem, thus they do not rely on search. We use the term 
simple divide and conquer for algorithms which have only a single decomposition 
operator. 

We chose to explore the synthesis of divide and conquer algorithms for 
several reasons: 

1 . Structural Simplicity - Divide and conquer is perhaps the simplest program 



Divide_and_Conquer (x) = if Primitive (x) 

then Divide_and_Conquer := Direct_Solution (x) 
else begin 

(x^,X2) := Decompose (x) ; 
y^ := Divide_and_Conquer (x-^) ; 

Y2 := Divide_and_Conquer (X2) ; 
Divide_and_Conquer := Compose ^^2) 
end 

Figure 1 . A divide and conquer program schema 
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structuring technique which does not appear as an explicit control structure in 
current programming languages. Our description of the structure of divide and 
conquer algorithms is based on a view of them as computational homomorphisms 
between algebras on their input and output domains. Careful choice of program- 
ming language constructs allows us to express divide and conquer algorithms con- 
cisely and in accord with their essential structure as a computational homomor- 
phism. 

2. Computational Efficiency - Often algorithms of asymptotically optimal com- 
plexity arise from the application of the divide and conquer principle to a 
problem. Fast approximate algorithms for NP-hard problems frequently are based 
on the divide and conquer principle. 

_3. Ubiquity in Programming Practice - Divide and conquer algorithms are common 
in programming, especially when processing structured data objects such as 
arrays, lists, and trees. Current textbooks on the design of algorithms stan- 
dardly present divide and conquer as a fundamental programming technique [1]. 

The basic concepts underlying our approach to program synthesis are 
presented in Section 2. While we have attempted to make this paper self- 
contained, some knowledge of first-order logic and automatic theorem proving 
techniques is presumed in Section 2.5. A system for top-down program synthesis 
is outlined in Section 3 together with the special knowledge needed to syn- 
thesize simple divide and conquer algorithms. A detailed illustration of the 
synthesis process is provided in Section 3.4 with the derivation of a selection 
sort. Less detailed but complete derivations are given in Section 4 of three 
other sorting algorithms. We distribute discussion of related research efforts 
and historical context among the appropriate sections. 
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2. Basic Concepts 



2.1 Specifications 



A program synthesis system requires as input a description of a problem to 
be solved. Specifications are a precise notation for describing the problem we 
desire to solve without necessarily indicating how to solve it. For example, 
the problem of sorting a list of natural numbers is may be specified as follows* 1 

Sort:x = z such that Bag:x=Bag:z A Ordered:z 
where Sort: LIST(3N) -> LIST (IN). 

Here the problem is named Sort which is a function from lists of natural numbers 
(denoted LIST(IN)) to lists of natural numbers. Naming the input x and the out- 
put z, the formula Bag:x=Bag:z A Ordered:z, called the output condition, 

expresses the conditions under which z is an acceptable output with respect to 
input x. Here Bag:x=Bag:y asserts that the multiset (bag) of elements in the 
list y is the same as he multiset of elements in x. Ordered :y is a predicate 
which holds exactly when the elements of list y are in nondecreasing order. 
Generally, a problem specification (or simply a specification ) || has the form 

1 1 ;x = z such that I:x =¥ 0:<x,z> 
where || : D -» R. 

We ambiguously use the symbol || to denote both the problem and its specifica- 
tion. Here the input and output domains are D and R respectively. The input 

condition expresses any properties we can expect of inputs to the desired pro- 
gram. Inputs satisfying the input condition will be called legal inputs. If an 
input does not satisfy the input condition then we don't care what output the 
program produces. The output condition 0 expresses the properties that an out- 
put object should satisfy. Any output object z such that 0:<x,z> holds will be 
called a feasible output with respect to input x. More formally, a problem 
specification (specification) If is a 4-tuple <D,R,I,0> where 
D is a set called the input domain, 

R is a set called the output domain, 

I is a relation on D called the input condition, and 
0 is a relation on DXR called the output condition. 

— ; 

We use the notation f:x to denote the result of applying the function or 
program f to argument x. 
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The intention is that a program F satisfies a problem specification || if on 
each legal input F computes feasible output. More formally, program F satisfies 
problem specification || =<D,R,I,0> if 

Vx€D[I:x =» 0:<x,F:x>] (2.1.1) 

o 

is valid in a suitable first-order theory. We say || is a complete specif ica- 
tion of F if formula (2.1.1) is valid, otherwise it is an incomplete specifica- 
tion. Specification || =<D,R,I,0> is unsatisf iable if 

Vx€D Vz€R [I:x =£> ~0:<x,z>] 

is valid. In words, || is unsatifiable if for each legal input there is no 
feasible output. 

The definition of "satisfies" can be weakened slightly with the following 
ideas in mind. For several reasons we may not know what the input condition for 
a problem should be. Most importantly, the input conditions under which the 
output condition can be satisfied may be difficult to know ahead of time. That 
is, the class of inputs for which there exists feasible outputs may not be known 
or easily describeable. Also, within the computational or competence limits of 
a synthesis system it may not be possible to find a program which works on all 
legal inputs. In both cases we would like the synthesis system to "do the best 
it can" and yield a program F together with an input condition under which F is 
guaranteed to terminate with a feasible output. These considerations lead to 
the following definition: Program F satisfies specification || =<D,R,I,0> with 
derived input condition if 

Vx€D [I':x A Isx =» 0:<x,F:x>] 



is valid. 

Note that a synthesis system employing this weaker concept of satisfaction 
can always generate a correct output; if the given problem is too hard it can 
always return a do-nothing program with the boolean constant FALSE as derived 
input condition. However, as we shall see, this concept of a derived input con- 
dition plays a more serious and integral role in our method in that they are 
used to construct certain predicates. Of course the synthesis of a program 
involves trying to make the derived input condition as weak as possible. We 

— 

- A suitable first-order theory is discussed in Section 2.5. It is assumed 
in this paper that all predicates involved in a specification are total. 
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^±so note that a system based on this definition of satisfaction allows the 
user to ignore input conditions when formulating a specification. However, 
deriving an input condition may require considerable computation which could be 
saved if the user supplies a correct or nearly correct input condition ini- 
tially. 

As an example, suppose a program synthesis system is given the specifica- 
tion 



Select :x = <a,z> such that a£Bag:z A Bag:x = Add:<a,Bag:z> 
where Select: LIST (]N) -» ]N X LIST( ]N) . 

Here we wish to split a list x into two components, a number a and a list z such 
that a is no larger than any element of z and the collection of elements in x is 
the same as the collection of elements in z with a added. This specification is 
incomplete in that there is no feasible output with respect to legal input nil 
(nil denotes the empty list). Our synthesis method would return a satisfying 
program (see Section 3.5.2) with derived input condition x^nil. Ibis condition 
is then used as a guard on the invocation of Select. 



2.2 Target Programming Language 

We will express algorithms in a typed functional programming language FPL 
based on Backus' FP systems [2]. In a functional programming language programs 
are viewed as a hierarchy of functions. Such languages come equipped with a set 
of primitive functions and a set of combining forms which are used to create 
complex functions from simpler ones. FPL differs from the FP-system in Backus' 
paper by allowing data types, new combining forms called function products and 
nondeterministic conditionals, and a little syntactic sugar. 

An FP-like system such as FPL can be described in terms of the following 
components: 

1. a set of data types and a set of data objects 

2. a set of primitive functions 

3. an operation called application 

4. a set of combining forms 

5. a function definition mechanism. 
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Data Types and Data Objects 



The data types of interest in this paper are IN (natural numbers), LIST(]N) 
(linear lists of natural numbers) , and B (boolean values TRUE and FALSE) . The 
symbol called bottom or undefined, is a data object and any elements of the 
preceeding data types are data objects. If x^,...,x n for n>^0 are data objects 
then the n-tuple <Xj,...,x n > is also a data object. If some object in a n-tuple 
is J_ then the n-tuple is X; i-e., <. . . ,X/ • • •> = X* For the purposes of specify- 
ing, discussing, and reasoning about programs we extend the usual equality rela- 
tion so that it is defined when one of its arguments is X* 'Ihe function 
Defined :x will be used to distinguish X from other objects. For example. 
Defined :X = FALSE, Defined :<1, 3, 5> = TRUE. 

Application 

The application of a function f to an object x, written f:x, denotes the 
object which results from applying f to x. 

Functions 

All functions map a data object to a data object. If a function requires n 
arguments for some n^O, then it is applied to an n-tuple of objects. Simi- 
larly, if a function generates m outputs it returns an m-tuple of objects. 
Functions in the system are either primitive (supplied with the system) or func- 
tional forms (created from other functions by means of combining forms) . The 
primitive functions of FPL are listed below in Figure 2 according to data type. 
For the natural numbers we have the usual addition function, denoted +, the com- 
parison functions <, _< , = , ^ , X />/ and the identity function, denoted Id. On 
the data type LIST(IN) we use the functions First, which returns the first ele- 
ment in a list. Rest, which returns its input list minus the first element. 
Cons, which adds a number to the front of a list. Append, which concatenates two 
lists. Length, which returns the length of a list, and the identity function, 
denoted Id. Not included in the table are the selector functions 1, 2, etc. 

defined on tuples. For example, 2:<3, (1,2,3) ,5> = (1,2,3) , 2:<1>=X* All func- 
tions in FPL are X-P^s^ving in that f:X = X holds for each function in the sys- 
tem. 

Combining Forms 

Combining forms are used to create a new function from other functions. 
The following four combining forms will tie used: 
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1. B (Boolean) 

2. IN (natural numbers) 



example values: TRUE, FALSE 

example values: 0, 1, 2,... 



name 

functions: + 

£ r~ r i 

Id (identity) 
3. LIST ( IN ) (Lists of Natural Numbers) 

name 

functions: First 

Rest 

Cons 

Append 

Length 

Id 

Figure 2. Data Types and 



examples 
+:<3,5> = 8 
< :<3,5> = TRUE 
^ :<3,5> = false 
Id: 3 = 3 

example values: nil = () , (1,2), (4) 
example 

First: (2,5,3) = 2 
First: () =X 
Rest: (2,5,3) = (5,3) 

Rest:nil =J_ 

Cons: <2, (5, 3) > = (2,5,3) 

Cons:<2,nil> = (2) 

Append: <(2,4) , (5,3,2) > = (2, 4, 5, 3, 2) 

Length: (2, 4, 5, 3) = 4 

Length :nil = 0 

Id: (2, 4, 5, 3) = (2,4, 5,3) 

Primitive Functions in FPL 



JL. Composition - The composition of functions f and g is written f *g and is 
computed by first applying g to the data object then applying f to the result, 
so for all data objects x (f *g) :x = f : (g:x) . 

For example: Length • Rest : (1, 3, 5) = Length: (Rest: (1,3,5) ) 

= Length: (3,5) 

= 2 

2. Construction - If fp...,f are functions and x a data object then the con- 
struction of these functions is written [f^,..., f n ] and is defined by 
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f n ] :x = <f x :x. 



• • • / 




For example: [First, Rest] : (1, 3, 5) =<1,(3,5)> 

3. Product - Hie product of unary functions f 1# ...,f n , written fj_X ••• Xf n / is 
defined by 



for all data objects Xj r ...,x n . 

For example: Id X Length: <3, (1,3,5,7)> = <3,4>. 

4. Nondeterministic Conditional - If qj/ * • • »q n are boolean functions or con- 
stants and f 2 , . . - , f n are functions or data objects then 



is a nondeterministic conditional form [8]. Curing application to object x each 
of the boolean functions, called guards , are applied to x. If any of the quards 
evaluates to or if none of the quards evaluate to TRUE, then the form evalu- 
ates to _]_• Otherwise one of the guards, say q^ , which evaluates to TRUE is non- 
deterministically selected and the form evaluates to f^:x. 

For example, 



is a simple if-fi form mapping ]N X IN into ]N and computing the minimum of two 
natural numbers. On application to <2,3> the guard £:<2,3> evaluates to TRUE 
thus the form evaluates to 1:<2,3> = 2. Note that on application to <3,3> both 
guards evaluate to TRUE thus either branch of the conditional can be taken. 
Although either branch can be taken the result is the same for this function. 

Definitions 

A definition is written 1 = r where 1 is the name of the function being 
defined and r is a functional form. For example, we can name the minimum func- 
tion defined above: 



Hereafter we will sugar the above notation for the sake of readability by 
1) allowing the left and right hand side of definitions to name their operands. 



f 2 X • • • X f|-j • ‘bCj, ... ,X n > — <f 




if q^ fj_ D 0 q n f n 



if < 4 1 1 > -4 2 fi 



min = if < -> 1 | -42 fi 
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2) allowing binary boolean functions which are conventionally written in infix 
notation to be so expressed, 3) write 

if 

q^:x -» f j^:x Q 

• • • 

q n :x f n :x 
fi 

for conditional forms, and 4) whenever possible replace selector functions on 
n-tuples by the name of the object or functional form which results from their 
application. Thus we will write the definition of the minimum function in the 
form: 



Min:<x,y> = if 

x_<y -» x 0 
x > y -» y 
fi 

As a more complex example of a function in FPL consider the following 
recursive definition of Select, which was specified in the previous section, 
ihis function is a crucial component of a selection sort function and will be 
synthesized later. Given a nonempty list of natural numbers the job of Select 
is to split it into a 2-tuple containing the least element and the rest of the 
list. 



Selectix s if 

Rest:x=nil [First, Rest] :x 0 
Rest :x ^ nil -» Compose* (Id X Select) • [First, Rest] :x 
fi 

Compose :<v <V2»z» = if 

v^£v 2 -» <VjyCons:<V2,z» 0 
v l — v 2 <v 2 /Cons:<Vi,z» 

fi 

Here is a simple evaluation of Select on the list (2, 5, 1,4) 
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Select: (2, 5,1,4) = Compose* (Id X Select) • [First, Rest] : (2, 5, 1,4) 

= Compose* (Id X Select) :<2, (5,1,4)> 

= Compose :<2,<1, (5,4) » 

= <l,Cons:<2, (5,4) » 

= <1, (2,5,4)> 

where Select: (5,1,4) evaluates to <1,(5,4)> in a similar manner. 

Select exemplifies the structure of simple divide and conquer algorithms, 
when Rest:x=nil then the problem is solved directly, otherwise the input is 
decomposed via the construction [First, Rest] , recursively solved via the product 
(Id X Select) , and the results composed via Compose. 

There are several reasons for introducing FPL rather than using a known 
language such as LISP. First, programs in this functional language have a 
hierarchic structure which facilitates top-down program synthesis. To construct 
a function from a given specification we must know how to select an appropriate 
combining form and adapt it to the given problem. The adaptation involves find- 
ing functions for each of the slots in the combining form - either by supplying 
a primitive function or by deriving a specification for it. For the adaptation 
to be successful we must show that if the specifications for the component func- 
tions are satisfied then the resulting functional form will satisfy the original 
specification. One point to note here is that much of the knowledge needed by 
the synthesis process is related to the individual combining forms (i.e., how to 
adapt a certain combining form to a given specification) and the primitive func- 
tions (how to know when a primitive function satisfies a given specification). 
So the structure of the language provides a natural organizing framework for the 
programming knowledge required by a top-down program synthesizer. 

In Section 3.2 we present a program schema for a class of divide and con- 
quer algorithms and the programming knowledge needed to adapt it to a specifica- 
tion. It can be viewed as a derived combining form since it is expressed in 
terms of the primitive combining forms supplied with the language. 

A second reason for introducing this language is that it allows an elegant 
rormulation of divide and conquer programs. Compare, for example, the divide 
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and conquer program schema in Figure 1 with its expression in FPL: 

DC:x = if 

Primitive:x -> Direct_Solution:x Q 
~Primitive:x -> Compose* (DC X DC) -Decomposer 
fi 

The language frees us from the need to overdetermine the order of evaluation of 
certain operations which are naturally independent. For example, in condition- 
als we are not forced to determine the order in which the guards are to be 
evaluated - they are conceptually evaluated in parallel. Also, the construction 
and product forms allow us to express processes which might otherwise require 
the storing of data and an arbitrary ordering of function evaluations. This 
conceptual parallelism is useful in expressing the functions synthesized in this 
paper and simplifies the synthesis process. 



2. 3 Program Termination and Well-Founded Orderings 

Ensuring that a constructed program will terminate on all legal inputs (or 
more generally determining the input conditions under which it will terminate) 
is crucial to the usefulness of a synthesis method. The usual method for show- 
ing the termination of a recursive program depends on the existence of a well- 
founded ordering on the input domain. 

A structure <W, }•> where W is a set and )• is a binary relation on W is a 
well-founded set and is a well-founded ordering on W if: 

1) ^ is irreflexive: uj^u for all u€w 

2) is assymetric: if uj-v then vj^u for all u,v£W 

3) is transitive: if uj»v and v J-w then u J-w for all u,v,w€w 

4) there is no infinite descending sequence Uq}- u i^* u 2^**** *- n 

For example, ]N (natural numbers) with the usual 'greater than' relation > forms 
a well-founded set denoted <]N,». More generally (k-tuples of natural 
numbers) has a well-founded ordering denoted where: 

<n^,..., n^> >k <n'j,..., n'| < > iff there is some constant m, l£m<k, such that 

n^ =n'- for each i<m and > n' m 

So for all k^l <]N* < ,>| C > is a well-founded set. 
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A recursive program P with input domain D can be shown to terminate on all 
inputs in the following way. First, a well-founded ordering ^ is constructed 
on D. Then, we show that for any x€D P applied to x only generates recursive 
applications (calls) to inputs x' for which x^x'. There can be no infinite 
sequence Xq,x 1 ,X 2 ••• such that applying P to x^ results in the application of 
P to + 1 for i >_0 since the well-founded ordering does not allow Xq^x^ 
• The above steps for ensuring program termination are an integral 
part of the synthesis method described below. 

A program synthesis system will have knowledge of some standard well- 

1 / 

founded sets such as <]N,» and <]N ,> k > but it need not anticipate ahead of 
time all domains which will require well-founded orderings. Consequently a 
method for constructing well-founded orderings is needed. The following theorem 
asserts that if we have a domain E and a known well-founded set <W, then any 
function from E to W can be used to define a well-founded ordering on E. 

Proposition _1. Let E be a set, let <W, ^> w > be a well-founded set, and let 
h:E -> W be a function from E into W. The relation ^ E defined by: 

u $- E u' iff h (u) ^(u’) 
is a well-founded ordering on E. 

Proof: 1) is irreflexive - for any u, h:u Jj-v/ 1 :u, but then by definition 

u !f > E u * 

2) ^ e ^ assymetr ic — if u ^ E u * then h(u) h ( u * ) and h ( u 1 ) Jf’W h(u) 
(by assymetry of ^ w ) thus u' V- 

3) is transitive - if u^ E u' and u' }- E u" then h(u)}- w h(u') and 
h(u') >-w h ( u ") * h( u ) K/h(u" ) follows by transitivity of ^ w , then u^ E u" follows 
by definition of ^ E . 

4) <E, ^ E > has no infinite decreasing sequence - if u Q ^g u-^g u 2 ^ E 

... then h(Up) h(u^) h(U 2 ) ... contradicting the well-foundedness of 

<W, J- w >. QED 

Proposition 1 enables us to establish a well-founded ordering on LIST(]N) 
(list of natural numbers) by simply finding a function from LIST(]N) to U. A 
suitable primitive function is Length, so we may define 
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x>-y iff Lengthrx > Length:y 



for all x,y € LIST( IN) . By Proposition 1 we conclude that <LIST( IN) , }-> is a 
well-founded set. Similarly, Length X Length (which maps LISTT( ]N) X LIST( IN) to 
IN X IN) can be used to construct a well-founded ordering ^ 2 on 
LIST ( IN ) X LIST (IN) where 

<x,y>>- 2 <x',y , > iff Length X Length :<x,y> > 2 Length X Length:<x' ,y’> 
iff Lengthrx > Length (x') or 

(Length :x = Length (x') and Length(y) > Length(y')) 



and so on. 

Proposition 2: If <W, J- w > is a well-founded set then <V 1 X V 2 X ...V k ,}- V > 
where Vj =W for some i € {l,2,...,k} and is defined by 

< u 1 ' u 2 , . . .u k > >- v <v lf v 2 ,.. .v k > iff u i 

is also a well-founded set. 



2. 4 Many -Sorted Algebras 

Algebraic concepts are playing an increasingly important role in formulat- 
ing the fundamental notions of computer science. In this paper we show that 
divide and conquer algorithms can be usefully characterized in algebraic terms. 
In particular they can be viewed as homomorphisms between appropriately defined 
algebras on the input and output domains. Accordingly, the synthesis method 
described later involves the construction of these algebras. In this section we 
present the basic terminology of many-sorted algebras based on and extending the 
notation of [11,12]. 

For any n€lN let in = {1,2, ...,n). If A is a set, then A + will denote 
a OLD - the extension of A to include the symbol for undefinedness. As usual 
the cartesian product of sets A^, A 2 ,..., Aj^ is written A^ X A 2 X • • ♦ X ^ and 
denotes {<ai,a 2 , . . . ,a n > | a^€A^ for i€n}. Parentheses are used for nesting so 

X (^2 ^ ^3^ = ^a 2 ,a I a^€Aj, a 2 € A 2 , a^CA^} 

the set of 2-tuples whose first component belongs to A^, and whose second com- 
ponent belongs to A 2 XA^. 
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Generally, we use the term simple many-sorted algebra to denote a collec- 
tion of sets equipped with an operator defined on cartesian products of the 
sets. Let S denote a set of symbols called sorts . A simple S -sorted signature 
£ of type <w,§> where w€S*, §€S is a set containing a single operator symbol 
of type <w,§>. Let < A s > s £g be an ^-indexed family of sets. If w€S* and 

w = w 1 w 2 ...w n then A w denotes the cartesian product A^ X A^ X ••• X A w . A £- 

algebra A consists of a family of sets <& s > s £ g called the carriers of A, and an 
operator denoted cr A where <x A :A w A^. A^ will be called the principal carrier 

of A. A ^-algebra A will be written A = <{Cp...,C^},{f}> where {C^,...,^} are 
the carriers of A and f is its sole operator. 

Let A and B be ^-algebras and let H = <h s > s £ s be an S-indexed family of 
functions where for each s€S, h g :A s B g . If w=w ] w 2** ,w n let h w denote the 
product function h w X h^ X ••• X ^ • Thus if a€A w then 

h w :a = <h Wl :a 1 , h w ^:a 2 , ..., h w ^:a n >. 

H = <h s > s £ S is a (S~) hoinoinor Phi sm from A to B if for each a€A w 

hg*°A :a = cr B ' hW:a - (2.4.1) 

i.e. the diagram in Figure 4 commutes. A ^-algebra will be called a composition 
algebra . 

We illustrate this notation with examples relating to data structures and 
divide and conquer algorithms. 

Example 2.4.1: Consider the sort set S = {a,b} and simple S-sorted signature £ of 




h w 

Figure 4: Commutative Diagram of a ^-homomorphism. 
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type <ab,b>. We describe two >-algebras called L and B as follows: 

L = <{]N,LIST(IN)}, {Cons}> 

B = <{ IN ,BAGS ( 3N ) } , {Add}> 

The carriers of L are L g = IN (natural numbers) and L b = LIST(lN) (lists of 
natural numbers) . The carriers of B are B g = IN (natural numbers) and 
B b = LIST(]N) (lists of natural numbers). The operator symbol cr in > is inter- 
preted in L as the function Cons, but in B is interpreted as Add (Add inserts a 
number into a bag of numbers); i.e. cr L is Cons and cr B is Add. 

Example 2. 4 . 2 } There is a natural homorphism between algebras L and B defined in 
Example 2.4.1. Let h a be Bag which maps a list of natural numbers x into the 
multiset of elements in x (e.g.. Bag: (1,3, 5, 3, 2) = {1,3, 5,3,2}) . Let h b be the 
identity function Id. First, h a and h b have the correct domains and codomains: 

Id: IN -» IN (h a : L a B g ) 

Bag: LIST(]N) -» BAGS ( IN ) (h fe : L b -» B b ) . 



Second, the homorphism condition (2.4.1) is satisfied: For each a € IN and 

x€liST(IN) 



Bag* cons :<a,x> = Add* (Id X Bag) :<a,x> 



(abstractly, h b *<r L :<a,x> = cr B * (h g X h b ) :<a,x>) . 



The inverse of a simple S-sorted signature £ of type <w,§> is a set 
containing a single operator symbol of type <§,w>. A ^-algebra A is a family 
of sets <Ag> s g B and an operator cr A : A g A w . Let A be a -'--algebra, B a 



£ialgebra, and let H = <h s > s g B be an S-indexed family of functions such that for 
each s€s h s :A s ->B S . H is a (^ ~ •*•£) - homomorphism from A to B if for each x€A 



such that <x A :x is defined 



h g :x = a B *h w *cr A :x (2.4.2) 

i.e., the diagram in Figure 5 commutes. A £ ~ ■'•-algebra will be called a decom- 
position algebra . 



Example ^.4 .^3: Consider a simple S-sorted signature £ of type <ab,b>. Consider 
LS and LC which are £ ~ ^ and ^-algebras respectively where: 
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h w 



Figure 5: Commutative Diagram of a £ ^-homomorphism. 



LS = <{IN,LIST(1N)}, {Select} > 

L£ = <{]N, LIST ( IN ) } , {Cons}> 

LS has carriers LS a = ]N and LS b = LIST(lN) and operator Select: LIST(IN) -» 
IN X LIST(]N) . Select splits a list of natural numbers into its least element 
and the rest of the list as discussed earlier. LC has carriers LC a = IN and 
LC b = LIST (IN) and operator Cons: IN X LIST (IN) -» LIST (IN). Letting h b be the 
function Sort, which sorts a list of numbers, and h a the identity function Id, 
we have a natural homomorphism from LS to LM. First, Sort and Id have the 
required domains and codomains: 

Id: IN -» IN (h a :LS a -» LC a ) 

Sort: LIST (IN) LIST(IN) (h b :LS b -» LC b ) 

and the homomorphism condition (2.4.2) is satisfied: for any x€ LIST (IN) such 
that Select :x is defined. 

Sort:x = Cons* (Id X Sort) *Select:x. 

Programmers will recognize this identity as the essence of a selection sort 
algorithm. It states that there are two ways to sort a list x: either apply 
Sort to x or decompose x via Select into a number a and list y, apply Sort to y 
yielding sorted list z then Cons a onto it. 

It will be useful to relax the definition of a £ ~ ^-homomorphism slightly 
in order to allow homomorphisms which map a restricted portion of a decomposi- 
tion algebra E to a composition algebra T. Let K be a relation on E^. A K- 

restricted £ ~ ^ homomorphism from E to T is an S-indexed family of functions 



- 19 - 



H = <hg> s g s such that 

1) h s : E s -> T s for each s€S and 

2) for each x€E such that K:x, h :x = cr T *h w *cr E :x. 

g s 

When K:x is Defined *<r E :x then we get back the original definition of a 2 -1 2- 
homomorphism. 



2. 5 Derived Preconditions 

The synthesis method described later consists of a sequence of tasks many 
of which are carried out by a kind of deductive engine described in this sec- 
tion. Only those aspects of the engine needed for our synthesis examples are 
presented here. More details may be found in [20]. 

2.5.1 The Precondition Problem 

Hie traditional problem of deduction has been to fknd a proof of a given 
formula in some theory. A more general problem, which we call the precondition 
problem , is most simply stated in the propositional calculus: given a goal A and 
hypothesis H, find a formula P, called a precondition, such that PAH =*> A is a 
tautology. In other words P provides any additional premises under which A can 
be shown to follow from H. 

In this paper we derive preconditions in a inany-sorted first-order theory 
•f. The data types, functions and predicates of needed for our examples are 
listed informally in the Appendix. The notions of term, atomic formula, literal 
and (well-formed) formula have their usual meaning [15]. We make use of a dis- 
tinguished subset of the theorems of 'f called known theorems which are assumed 
to be immediately available to the deductive system. The set of known theorems 
may change over time but initially includes all axioms of •£. All of the known 
theorems required by the examples are listed in the Appendix. 

We introduce the notion of a precondition in a first-order logic by an 
example. Consider the following formulas 

Vi€w Vj € ]N [i 2 <j 2 ] (2.5.1) 

Vi€n Vj€H [i = 0 =» i 2 < j 2 ] (2.5.2) 
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The first is invalid, the second valid. All that we have done in (2.5.2) is 
insert a sufficient condition, i=0, on the matrix i < j in (2.5.1). We call 
"i=0" an {i}-precondition of (2.5.1) because it contains only the variable i, 
and when we use it as we did in (2.5.2) we obtain a valid statement. 

Formally, let Q^x^ Q2 x 2***^n x n G be a closed formula not necessarily in 
prenex form where Qj is either 3 V for i=l,2,...,n. A {xix 2 ...x n }- 

precondition of Q^x^ Q2 x 2***^n x n G i s a quantifier-free formula P dependent only 
on variables xi,x 2 ,...,x n such that 

g 1 x 1^2 x 2* * *^h x n t ] 

is valid in P is also a weakest (x^-,. . .x,,} -precondition if 



is valid in •}». 



Q 1 x 1 Q 2 x 2 ...C^x n [ P<=^G ] 



Example 2.5.1: Consider the formula Vi€lN Vj € IN [i 2 _<j 2 ] 

a) FALSE is a {} -precondition of (2.5.1) since 
Vi€]N Vj € IN [FALSE => i 2 £j 2 ] is valid in 

b) i=0 is a {i}-precondition of (2.5.1) since 
Vi€u Vj € ]N [i=0 =» i 2 <j 2 ] is valid in •£. 

c) i < j is a { i , j } -precondition of (2.5.1) since 
Vi € IN Vj € IN [i < j =» i 2 j 2 ] is valid in 

Furthermore, note that each of the above preconditions are in fact weakest 
preconditions since the implication signs can each be replaced by equivalence 
signs without affecting validity. Note also that for any goal formula and set 
of variables the constant FALSE is a precondition. 

In general a given goal may have many preconditions. Characteristics of a 
useful precondition seem to depend on the application domain. In program syn- 
thesis we want preconditions which are a) easily computable, b) in as simple a 
form as possible, and c) as weak as possible. (Criterion (c) prevents the 
boolean constant FALSE from being an acceptable precondition for all goals.) 
Clearly there is a tradeoff between these criteria. We currently measure each 
criterion by a separate heuristic function, then combine the results to form a 
net complexity measure on preconditions. We assume that such a complexity meas- 
ure ranges over a well-founded set (such as IN under the usual > relation) and 
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that we seek to minimize complexity over all preconditions. 



Example 2 . 5 . 2 : Consider again the formula Vj € D [i 2 _< j 2 ] for which we 

o o 

want a useful {i , j > -precondition. Three candidates come to mind: FALSE, i* < j% 
and i < j. FALSE is certainly simple in form and semantics but it is not weak. 
Both i 2 < j 2 and i< j are weakest preconditions however i£j is the simpler of 
the two. Thus i _< j seems the most desireable. 

The generality of the precondition problem allows us to define several 
well-known problems as special cases. The formula simplification problem 
involves transforming a given formula into an equivalent but simpler form. For- 
mula simplification can be viewed as the problem of finding a weakest 
{x-i , .. .x n } -precondition of a given formula Q^. • *C^ x n G. For example in the 
previous example we found i _< j to be a result of simplifying i £ j . 

Theorem proving is the problem of showing that a given formula is valid in 
a theory by finding a proof of the formula. In terms of preconditions, theorem 
proving is the task of finding a weakest {} -precondition of a given formula. A 
precondition in no variables is one of the two propositional constants TRUE or 
FALSE. If we show that 

3 i € 3NVj € 3N[TOUE 4=*> i 2 <j 2 ] 
is valid in then we also have shown that 

3i€ ]NVj€ IN [ i 2 _< j 2 ] 

is valid in 

Formula simplification and theorem proving are opposite extremes in the 
spectrum of uses of preconditions since one involves finding a weakest precondi- 
tion in all variables, and the other involves finding a weakest precondition in 
no variables. Between these extremes lies a use of preconditions which is crit- 
ical to the synthesis method described later. Suppose that we wish to establish 
a relationship 

Vx 2 VX 3 Vx 4 [A:<x 1 ,x 2 >AB:<x 2 /X 3 >AC:<X 3 ,X 4 > =» D:<X 2 ,X 4 >] (2. 5. 3) 

where B, C, and D are known, but A is unknown and needs to be determined. Any 
{x 1 ,x 2 }-precondition of (2.5.3) can be used for A. To see this let k , :<x 1 ,x 2 > 
be any such precondition so 

V x 2 Vx 2 Vx 3 Vx 4 [A':<x 1 ,x 2 >=» (B:<x 2 ,x 3 >AC:<x 3 ,x 4 >=»D:<x 1 ,x 4 »] 
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is valid. But this is equivalent to 

N/Xi V * 2 Vx 3 Vx 4 [A , :<x 1 / x 2 >AB:<x 2 / x 3 >AC:<x 3 ,x 4 >=»D:<x 1 ,x 4 >] 

In this example precondition derivation is similar to solving a linear equation 
in which all but one of the variables have been given values. A relation analo- 
gous to (2.5.3) must be established among the operators of a simple divide and 
conquer algorithm (the "separability condition" of Theorem 1 in Section 3.2). 
When all but one of the operators are known we use preconditions in order to 
derive the output condition of the unknown operator. 

While we've shown that the precondition problem in a sense is more general 
than that of theorem proving we will see in the next section that actually 
deriving preconditions is much like a theorem proving process. The crucial 
difference is that in deriving a precondition P for a goal G we end up proving 
the validity of a formula involving P and G but we did not know ahead of time 
what we were going to prove! The proof process itself provides some of the 
premises of the formula which is finally proved valid. 



2.5.2 A Formal System for Deriving Preconditions 
Goal Preparation 



In presenting a set of rules which allow us to derive preconditions we use 
the notation ^ as an abbreviation of the formula 

h l A h 2 A ••• A h k =¥ A 

where H= {h 3 ,h 2 , . . . ,1^} . A goal statement ^ and the known theorems of are 
prepared as follows. First, all occurences of equivalence (^) and implication 
( =» ) signs are eliminated and negation signs are moved in as far as possible. 
H and the known theorems of are then skolemized in the usual way [14], i.e., 
existentially quantified variables are replaced by skolem functions of the 
universally quantified variables on which they depend. Quantifiers are then 
dropped with the understanding that all remaining variables are universally 
quantified. The goal A is skolemized in a dual manner with universally quanti- 
fied variables replaced by skolem functions of the existential variables on 
which they depend. All quantifiers are then dropped with the understanding that 
all variables in A which remain are existentially quantified. The preparation 
of A is equivalent (via duality of goals and assertions) to preparing -A as an 
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hypothesis then taking the negation of the result as our prepared goal. 

All of the derivations treated in this paper involve only universally quan- 
tified variables. Consequently during goal preparation each variable in the 
goal is replaced by a skolem function of no arguments (i.e. a constant). Rather 
than invent a special notation for these skolem constants we will simply use the 
variable name itself. Thus in example derivations symbols for variables, such 
as "x", should be regarded as skolem constants. 



Reduction Rules 

Rules which reduce a goal statement to two subgoal statements are expressed 
in the following form: 



< P 1> 



<P 0 > 



A 

H 



0 

0 




H n 



<P 2 > 



A 

H 



2 

2 



where AQ,Ap and A 2 are goal formulas, Hq, Hj, and H 2 are 
Pq, P^, and P 2 are formulas (the derived preconditions) , 



A* A rule of this form asserts that if P^ is a (weakest) 



where i=l or 2 then Pq is a (weakest) precondition of H . 



sets of hypotheses, 
and © is either V or 

A i 

precondition of H . 
Pq generally is P^ 



Typically a deductive process also returns a substitution for any variables 
in the goal. Substitutions do not play an important role in the examples of 
this paper so for simplicity we omit them whenever possible. They are fully 
treated in [20]. 



Rules which reduce a goal statement to one subgoal are notated 



< p 0> 



A 

H 



0 

0 



< P 1> 



A 

H 



1 

1 
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Occasionally, as in the application of known theorems which are implica- 
tions, the relation between goal and subgoals is not one of equivalence but 
implication. Rules of this kind are notated 



<p„> 



A 

H 



0 

0 






< P 1> 



A 

H 



1 

1 



. . A i 

which asserts that if is a precondition of then P Q is a precondition of 
A n 

H . For rules of this kind we cannot assert that P Q is a weakest precondition 

A A 

of even if P^ is known to be a weakest precondition of 

The following rules are for the most part extensions of typical goal reduc- 
tion rules [5,14]. 



Rl. Reduction of Conjunctive Goals 



<P 1 A P 2 > A A B 
H 




<P 1 > A <P 2 > B 

H H 



R2. Reduction of Disjunctive Goals 



<P 1 V p 2 > A V B 




<P2> A <P 2 > B 

H H 
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R3. Application of an Equivalence Theorem 



<P> A 
H 



<P> CG 
HG 



if C4=^B is a known theorem of 
or an hypothesis in H and G unifies {A,B} 



R4. Application of an Implicational Theorem 



<P> A 
H 



<P> CG 
HG 



if C=^B is a known theorem of •f 1 
or hypothesis in H, where G unifies {A,B} 



R5. Substitution of Equal Terms 



<P> A(r) 
H 



<P> 



A„ (S) 



if r=s is an hypothesis in H 
or a known theorem of 



R6. Conditional Equality Substitution 



<P> A(r) 

H 

If B =#• S 2 =S 2 is a known theorem 
where G^ unifies {r^} and 
G 2 unifies BG^ with a 
hypothesis or known theorem. 

<P> A(s 2 )G 1 G 2 

H©1 6 2 



Primitive Rules 

A reduction rule generates a precondition for a goal by decomposing it into 
subgoals, then composing the derived preconditions of the subgoals. We also use 
two rules, called primitive rules, which can directly generate a precondition 
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which 



for a goal. Both are described by notations of the form ^ 

assert that P is a precondition of ^ if the associated condition holds. 



D1 <TRUE> A 
PI. H 



if A can be directly evaluated to TRUE, or if 9 unifies 
{A,B} where B is a known theorem of or B€H. 



P2. 



<H' =»A’> 



A 

H 



if we seek a {x^/ ••• *x n } -precondition and A' depends only 

n 

on the variables x-i,...,x and H' has the form A h.- where 

j = 1 j 

H = {hjyl^f . . . fh^} and {h^ . } j _ G H and for each j, 

1<C j_<m, hj . depends only on the variables x^^/ • • . ,x n . 



The primitive rule PI always generates weakest preconditions but P2 does not in 
general unless A' is A and H' is H. 



The Deduction Process 

The derivation of a precondition of goal statement ^ can be described by a 
two stage process. In the first phase reduction rules are repeatedly applied to 
goals reducing them to subgoals. Primitive rule Pi is applied whenever possi- 
ble. If no reduction rules can be applied to a goal (or if we simply desire to 
cut short the deduction) primitive rule P2 is applied. The result of this 
reduction process is a goal tree in which 1) nodes represent goals/subgoals, 2) 
arcs represent reduction rule applications, and 3) leaf nodes represent goals to 
which a primitive rule has been applied. 

The second phase involves the bottom-up composition of preconditions. Ini- 
tially each application of a primitive rule to a goal yields a precondition. 
Subsequently whenever a precondition has been found for each subgoal of a goal ^ 
then a precondition is composed for ^ according to the reduction rule employed. 
Each newly composed precondition is then run through a simplification process. 

Usually several reduction rules can be applied to a given goal and each 
rule will generate a precondition. We make use of a complexity measuring func- 
tion to select that precondition of least complexity among the alternatives. 
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Example 2.5.3: Suppose that we wish to derive a {x 0 ,x 1/ x 2 }-precondition of 

V<x 0 ,x 1 ,x 2 >€LIST(]N) XLIST(M) XLIST(W) 

V<z 0 ,z lf z 2 >€ LIST(K) X LIST(W) X LIST(W) 

[Bag:x^ = Bag:z^ A Ordered :z^ A Bag:x 2 = Bag:z 2 A Ordered:z 2 A 
Append :<z lf z 2 > = Zq =» Ordered:z Q ] . 

This precondition problem is taken from the synthesis of a Quicksort algorithm 
in Section 4.3.3. A goal tree representing a formal derivation of the precondi- 
tion Bag:x^ _< Bag:x 2 is given in Figure 6. In this example and all that follow we 
annotate the arcs of goal trees with the name of the rule and known theorem or 
hypothesis used and note the primitive rule used on each leaf node. In this 



Hypotheses: hi. Bag.'x^ = Bag:z^ 



h2. Ordered :Zj 
h3. Bag:x 2 = Bag:z 2 
h4. Ordered :z 2 
h5. Append :<z 1# z 2 > = z Q 



Variables: {x n ,x lf x 7 } 



0 ' x 1' a 2 



Goal 1: 



<Q> Ordered :Z q 
R 5 + h5 

<Q> Ordered :Append:<Zj,z 2 > 

| R3 + LI 3 

<Q> Ordered^ A Ordered:z 2 A Bag:z-j £Bag:z 2 




<TRUE> Ordered :z^ 
PI +h2 



<TRUE> Ordered:z 2 <Q> Bag:z 1 £Bag:z 2 



PI +h4 



R5 + hi, R5 + h3 



<Q> Bag:xj_< Bag:x 2 
P2 



where Q is Bag:xj <^Bag:x 2 



Figure 6: Example Derivation of a Precondition 
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example the given goal Ordered :Z q is reduced by application of the rule R5 
(equality substitution) together with hypothesis h5. The resulting subgoal 
Ordered: Append :<ZpZ 2 > is further reduced by rule R3 (application of equivalence 
theorems) together with the known theorem 

Ordered^ A Ordered:x 2 A x i <. x 2 ^ Ordered -Append :<Xi,x 2 >. 

(called L13) to the subgoal 

Ordered .-Zj A Ordered :z 2 A Bagrz-^ <_ Bag:z 2 . 

This conjunction is decomposed by two applications of rule R1 (reduction of con- 
junctions) into the three subgoals on the fourth line. Ihe primitive rule PI 
matchs the first subgoal Ordered:z^ with hypothesis h2, generating precondition 
TRUE. Similarly, PI matchs the second subgoal Ordered :z 2 with hypothesis h4, 
generating precondition TRUE. The third subgoal Bagrz-^^ Bag:z 2 is reduced by 
the application of rule R5 twice with hypotheses hi and h3 yielding subgoal 
Bag:xi£Bag:x 2 . This subgoal depends only on the variables x-^ and x 2 and we can 
apply primitive rule P2 yielding the precondition Bag:xi <Bag:x 2 (which we call 
Q for brevity). In the composition phase of the derivation the preconditions 
generated by the primitive rules are passed up the goal tree and composed. The 
composed precondition of the subgoal 

Ordered :Zj A Ordered :z 2 A Bagrz^^ Bag:z 2 

is in fact 



TRUE A TRUE A Bag :x-^ < Bag :x 2 

which simplifies to Bagrx^ £Bag:x 2 . In this example and the sequel we record 
only the simplified form of a composed precondition. Finally Bag:x^ < Bag:x 2 is 
passed all the way back up the tree to become the derived precondition of the 
original goal. 
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3. Top-Down Program Synthesis 



In Section 1 we discussed the notion of top-down design. We now describe 
the general structure of a system for the top-down design of algorithms. As 
depicted in Figure 6, the system takes as input a incomplete specification of a 
problem and generates as output an algorithm plus completed specification. The 
advantage of using incomplete specifications is threefold. First, the user need 
not be concerned with how to solve his/her problem but rather can focus on the 
nature and structure of the problem itself. Second, other than having the user 
supply a complete program, it is only with specifications that we are able to 
completely verify that the user's intentions have been met by a potential solu- 
tion. Finally, incomplete specifications are easier to create since the user 
need not be concerned with supplying all necessary input conditions - the system 
will supply them automatically. 

The programming knowledge needed for top-down program design is organized 
about the two central aspects of the design process: 1) how to directly 
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Figure 6. Structure of a Top-Down Program Synthesis System. 
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construct a solution to a so-called primitive problem, and 2) how to break a 
nonprimitive problem down into subproblems and assemble a solution based on 
solutions to subproblems. Knowledge about the first aspect is presented in Sec- 
tion 3.1. Broadly we envision knowledge of the second kind coming in the form 
of design theories for various classes of algorithms. A design theory consists 
of three parts: 

1. A program schema , which is a parameterized program template with uninter- 
preted symbols for subprograms. The program schema characterizes the structure 
common to algorithms in the class. 

2. A formula providing sufficient conditions for the total correctness of the 
schema with respect to a generic problem specification. Necessarily these con- 
ditions are formula schemas containing uninterpreted symbols for the specifica- 
tions of subprograms in the program schema, and for predicates in the problem 
specification. Note that they link a problem specification and a program 
schema . 

3. A design method which attempts to instantiate the schema in order to satisfy 
a given problem specification. It works by deriving subproblem specifications 
in such a way that the sufficient conditions are satisfied. Loosely speaking, 
in our approach a design method uses the sufficient conditions to "solve for" 
subproblem specifications. 

The main result of this paper is a design theory for the class of simple divide 
and conquer algorithms. 

The Programming Knowledge Base in Figure 6 consists of two parts. The Data 
Structure Knowledge Base stores all system knowledge about data types, their 
operators, and their properties. It is discussed in Section 3.1. The Library 
of Design Theories is a collection of design theories as discussed above. A 
program schema for the class of simple divide and conquer algorithms and suffi- 
cient conditions for correctness of the schema are presented in Section 3.2. In 
Section 3.3 we present our design method for simple divide and conquer algo- 
rithms. Several of our examples require the synthesis of simple conditional 
programs. A collection of design methods for conditional programs will be 
treated elsewhere, but assumed as given for our present examples. 

The Synthesis Control Module controls the top-down design process. Among 
its tasks are obtaining specifications from the user, selecting and applying 
design theories, and managing the resulting tree structure. Included in the 
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Control Module is a precondition engine as discussed in Section 2.5. 

We are currently constructing a system with the structure of Figure 6. A 
precondition engine has been built which can handle most of the derivations 
given in the example syntheses below. 



3. 1 Data Structure Knowledge Base 

The data structure knowledge base (DSKB) is the repository of all system 
knowledge about data types, their functions, algebras, and properties. The data 
types represented in the DSKB, called known data types, may change over time but 
initially include the primitive types of the target programming language. The 
functions of the DSKB, called known functions, also may change over time under 
user definition but initially include the primitive functions of the target 
programming language. The algebras in the DSKB, called known algebras, may also 
change over time but initially include at least one constructive algebra for 
each known data type. Logical statements involving the known data types and 
functions, called known theorems, also may change over time as new theorems are 
proved or added by a user but initially include the axioms which describe the 
primitive data types and functions of the programing language. The DSKB assumed 
for the purposes of this paper is presented in the Appendix. 

The organization (and structure) of the DSKB depends on the various roles 
it plays in the synthesis system. The DSKB is used as the lexicon of the 
specification language. We allow in specifications any formula constructable 
from the known types and functions. As the DSKB changes over time so does the 
specification language. From the specification language point of view the DSKB 
defines a first-order language. 

The precondition engine uses the DSKB as a knowledge base of theorems to 
use during its derivations. From this point of view the DSKB is a partial 
representation of a first-order theory (partial in the sense that only the known 
theorems are explicitly represented) . 

As previously indicated the synthesis method for divide and conquer pro- 
grams involves the construction of algebras on various domains. Thus organiza- 
tion of the data types and functions, relations, and theorems along the lines of 
algebras and subalgebras may be useful. 
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Although we do not include it here, ideally the DSKB also requires consid- 
erable programming knowledge of the kind described by Barstow in [3]. The rea- 
son is this: the synthesis method constructs a program out of known operators 
and relations mapping the input type to the output type given in the specifica- 
tion. If the input and/or output types or operators or relations are not primi- 
tive then the constructed algorithm must be further refined into target language 
primitives. Barstow has explored the kind of knowledge and processing required 
to perform this refinement process. 

Matching Known Functions Against a Given Specification 

The top-down decomposition process terminates in specifications which can 
be satisfied by known functions. Consequently a basic operation of the DSKB is 
to retrieve any known functions satisfying a given specification. Ihe following 
two theorems provide the basis for two variants of this operation. Proposition 
3 suggests a matching operation which is useful when we have a given specifica- 
tion and we wish to see if any of a library of functions, each described by a 
specification, satisfy it. Proposition 4 is useful when a known function is 
described not by specification but by axioms (known theorems) . 



Proposition 3: Let || 0^> and || 2 = <D 2 ,R 2 , I 2 ,0 2 > specifications. 

If 

(a) D 2 C D^ 

(b) R x R 2 

(c) J is an {x} -precondition of Vx€D 2 [I 2 :x ^ I i :x l • 

(d) K is an {x} -precondition of 

Vx€D 2 Vz€Si [l 2 :x A Oi.'<x,z> =#■ 0 2 :<x,z>] 

then any function satisfying || ^ also satisfies || 2 with derived input condition 
J A K. 

Proof: Let F be any function satisfying || thus 

Vx€D^ [I^:x =¥ 0^:<x,F:x>]. 

We must show 



Vx€D 2 [I 2 :x A J:x A K:x =S> 0 2 :<x,F:x>] 
where J and K are preconditions satisfying conditions (c) and (d) respectively. 
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Let x€D 2 and assume I 2 :x A J:* A K:x. By conditions (a) and (c) we can infer 
I^:x. Since F satisfies we obtain Oj.:<x,Fsx>. Since F:x€R lf and by condi- 
tion (d) K:x A l 2 :x A 0 1 :<x,F:x> =*> 0 2 :<x,F:x>, we obtain via modus ponens 
that 0 2 :<x,F:x>. Since x was taken as an arbitrary element of D 2 it follows 
that 



Vx€d 2 [l 2 :x A J:x A K:x =» 0 2 :<x,F:x>] 
i.e. F satisfies ]T 2 with derived input condition I 2 A >1 A K. QED 

Example 3.1.1: One of the known functions of the DSKB, called Listsplit, takes a 
list and splits it roughly in half. It is specified as follows: 

Listsplit:xQ = <Xjl,x 2 > such that Xq = Append :<X jl,x 2 > A 
Leng th:x 2 = Length :X q div 2 A Length :x 2 = (1 + Length:x 0 ) div 2 
where Listsplit: LIST(]N) LIST( Tti) X LIST( ]N) . 

By x div k we mean integer division by k. Thus 5 div 2 = 2. EXaring the synthesis 
of a mergesort algorithm we derive the following specification: 

Decompose :y Q = <yjL,y 2 > such that Length:y Q > Length:y 1 A Length:y Q > Length:y 2 
where Decompose: LIST (]N) LIST ( IN) X LIST ( IN) . 

We can match Decompose and Listsplit using Proposition 3. Since the input 
domain, the output domain, and the input condition coincide it remains to derive 
a {yQ}-precondition of 

V<y 0 /yi/y 2 > €LIST ( ]N ) XLIST(]N) XLIST(]N) [y 0 = append :<y p y 2 > A 
Length^^ = Length :yQ div 2 A Length :y 2 = (1 + Lengthy) div 2 
=¥ Length :yQ>Length:y^ A Length :yQ>Length:y 2 ] . 

We have created the precondition problem by making the following instantiations 
into the condition (d) of Proposition 3: 

LIST(]N) replaces Dj L ,Rj L ,D 2 ,R 2 

TRUE replaces 

the output condition of Listsplit replaces 0^/ and 

the output condition of Decompose replaces 0 2 * 

In Figure 7, we derive the precondition Length:yQ > 0 A Length:yQ > 1 which 

simplifies to Length:yQ>l. Thus according to Proposition 3 Listsplit satisfies 
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the specification of Decompose with derived input condition Length:y Q >l. This 
means that we can use the function Listsplit for the problem Decompose provided 
that it is never passed an argument of length zero or one. 



Hypotheses : 


1 . 


Xq = append :<x x 2 > 




2. 


Lengthsx^ = Length:Xg div 2 




3. 


Length:x 2 = (1 + Lengthrxg) div 2 


Variables: 


{x 0 } 




Goal 1: 




<Q1> Length :X q > Length :x-. 



| R5 +h2 

<Q1> Length:xQ > Length :X q div 2 
| R4 + n2 

<Q1> Length :X q + Length :X q > Length:x Q 

| R3 + nl 

<Q1> Length :Xg > 0 
P2 

where Q1 is Length :Xg>0 



Goal 2: 



<Q2> Length:xg > Length:x2 
| R5 + h3 

<Q2> Length:Xg > (1 + Length:x 0 ) div 2 

|R4 +n2 

<Q2> Length :xq + Length :xq > l + Length:Xg 



R3 + nl 
<Q2> Length :xg > 1 



P2 



where Q2 is Length:xQ>l 



Figure 7: Matching the specification of Decompose with the specification of Listsplit 
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Proposition 4: Let F be a function with domain and codomain and let 

J\ 2 = <d 2 ,R 2 ,1 2 ,0 2 > be a If 

(a) VxCDj [I^:x =» Defined*F:x] 

(b) d 2 g d x 

(c) G F ^2 

(d) J is an {x} -precondition of Vx€d 2 [I 2 :x ^ I i :x ] 

(e) K is an {x} -precondition of 

N/x€D 2 Vz€Ri[J:x A l2 :x /A '> z = F:x 0 2 :<x f z>] 
then F satisfies Tf 2 with derived input condition J A K. 

Proof: We must show 

V x €D 2 [I 2 :x A Ji x A K:x 0 2 :<x,F:x>]. 

Let x be an arbitrary element of D 2 and assume I 2 :x A J:x A K:x. By condition 

(d) we can infer Ij:x. Since D 2 £ D-^ we have x € and by condition (a) we can 

infer Defined*F:x. F:x is in R 2 since FtxGR^ C R 2 b Y condition (c) . Finally 

by condition (e) we can infer 0 2 :<x,F:x>. QED 

Proposition 4 is used when we do not have a specification for an operator F 
but its behavior is fully described by the known theorems of the DSKB. Such a 
situation arises for certain primitive functions of the target language. These 
are used to specify and define other functions but cannot themselves be 
described in terms of more primitive functions. Their behavior in relation to 
other primitive functions is instead described by axioms (known theorems) . All 
that is required for the matching operation suggested by Proposition 4 is 1) the 
domain and codomain of F, 2) conditions under which F is defined, and 3) 
axiomatic specification of its behavior. 

Example 3.1.2: The operator Cbns is described by its interaction with other 
operators such as First, Rest, and Bag. Letting x vary over LIST(]N) and a over 
]N, the usual axioms include: 

1. Cons* [First, Rest] :x = x 

2. First*Cons:<a,x> = a 

3. Rest* Cons :<a,x> = x 
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4. Defined * Cons: <a ,x> 



5. Bag* Cons :<a,x> = Add:<a,Bag:x>. 

we can use Proposition 4 to show that Cons satisfies the following specifica- 
tion: 

Il 2 :<a,x> = z such that Add :<a ,Bag :x> = Bag:z 
where ]7 2 : H X LIST( ]N) LIST(]N). 

The input and output domains of || 2 and Cons coincide. By axiom 4 we implicitly 
have TOUE as input condition for Cons, therefore we can derive TRUE for J in 
condition (d) of the theorem. Finally according to condition (e) we attempt to 
find an {a ,x} -precondition of 

V<a/X> C IN X LIST( IN) [TRUE A TRUE Add : <a , Bag :x> = Bag :Cons: <a ,x>] . 

This formula is easily shown valid by using axiom 5 above. Thus by Proposition 
4 we conclude that Cons satisfies || 2 with derived input condition TOUE. 

It may be that no single known function satisfies a given specification but 
that a structure of known functions will satisfy it. If the specification 
requests a mapping of type D-^ X • • • X D m R^ X • • • X Rp then a function structure 
of the form [f ^,f 2 . . . ,f n ] is required. A straightforward backtracking algorithm 
for placing these n functions can be used to find all potential structures. 
Chce a structure is found with the correct input and output types the matching 
operation can be invoked to verify satisfaction of the specification. 

Example _3*i*2 : Consider the specification 

|| :x = <a,z> such that x = Cons: <a,z> 
where U:LIST(]N) H X LIST( U) . 

Here a function structure of the form [f ^ , f 2 ] is required. For f^ we might con- 
sider all known functions mapping LIST(]N) to JN such as First, Length, Min, 
etc. For f 2 we might consider all mappings from LIST(]N) to LIST(]N) such as 
Rest, Sort, etc. Passing [First, Rest] to the matching operations described in 
the previous section we can derive x^nil as derived input condition. The 
derived input conditions for the other potential structures are not very weak so 
they are discarded. 
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3. 2 Problem Reduction Representations and Simple Divide and Conquer Algorithms 



A problem specification typically provides few indications of how to go 
about solving it. Rather than attempt to map directly from the specification to 
a satisfying program, our approach to synthesizing a divide and conquer algo- 
rithm proceeds by enriching the specification with additional structure in the 
rorm of algebras on the input and output domains. The construction of these 
algebras is constrained not only by each other but also by the input and output 
conditions. The result of this enrichment process is called a problem reduction 
representation of the original specification. A program may then be straight- 
forwardly constructed from the components of the representation. 

Let 2 be a simple S-sorted signature of type <w,§> where w€S , 
w = w-|yW2, . . . ,w n , and § € S. A ^ -problem reduction representation (£-PRR) is a 
system || = <E,T,J,P> 
where 

1. E is a 2 ~ ^-algebra called the input algebra 

2. T is a 5-algebra called the output algebra 

3. J = <J s > s g s * s an s- i ndexed family of relations on E 

(i.e. J s C E s for s€S) called the family of input conditions 

4. P = <P S > S g s is an S-indexed family of relations on EXT 

(i.e. P s Q E s X T s for each s) called the family of output conditions. 

For each s€S let || s , called a component problem , denote the problem specifica- 
tion <E S ,T S , J S ,P S >. || will be called the principal problem and for each 

s€S-§ || s will be called an auxiliary problem . jf represents specification 

J\ = <D,R, I,0> if IT = TT. 

§ 

An S-indexed family of functions F = <f s > s g s satisfies ^-problem reduction 
representation TT =<E,T,J,P> if 

A 

1. for each s€S, f s satisfies TT S = <E s ,T s ,J s ,Pg>, and 

2. F is a L-restricted homomorphism from E to T for some relation L on 

E . 

§ 

A A 

Clearly if F = <f s > s gg satisfies || and || represents || then f^ satisfies || . 

An S-indexed family of functions E = <f s > s gg is called a simple divide and 
conquer program if f has the form 
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f :x = if 
§ 

q:x -» h:xO 
~q:x -> exp* f w, Og:x 
fi. 

We call Og the decomposition operator, ctvj, the composition operator, f g an auxi- 
liary operator for each s€S-§, and h the primitive operator. The term "simple" 

is used to denote the restriction that f employs a single pair of composition 

§ 

and decomposition operators. Oar main synthesis task is to construct a £-PRR 
which represents a given specification then construct a simple divide and con- 
quer program which satisfies it. 

Theorem 1 characterizes programs which satisfy a £-PRR and provides the 
basis for the synthesis method presented in Section 3. Most of the conditions 
of Theorem 1 are straightforward requirements on the correctness of the programs 
f for each s€s. An exception, and perhaps the most interesting condition, is 
che "separability" condition. In words it states that if input Xq decomposes 
into subinputs x 1 ,...,x n , and z^, ...,z n are feasible outputs with respect to 
xdiese subinputs respectively, and Zi,...,z n compose to form Zq then Zq is a 
feasible solution to input Xq. Loosely put: feasible outputs compose to form 

feasible outputs. It is the principal link between the algebras E and T, and 
the input and output conditions. 

Theorem 1: (Sufficient conditions for the existence of a simple divide and con- 

quer solution to a problem reduction representation) Let || = <E,T, J,P> be a £- 

PRR where ^ is a simple S-sorted signature of type <w,§>, and let F = <f s > s g s 

an S-sorted family of functions. Let ^ be a well-founded ordering on E and 

§ 

let Og and 0 T be relations on E^ w and T^ w respectively. If 

(1) (Specification of <x E ) the decomposition operator cr E satisfies the 
specification 

°E :x 0 = <x l'*** ,x n > such that J :x Q ^ -A ( J w- :x i A (i = § =» x Q J-xj)) A 

s i c n l 

Og: <x^ / • • • fX^> 

where <x P :E E w 

E § 

with derived input condition Kg; 

(2) (Specification of cr,p) the composition operator <x T satisfies the 
specification 
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CTijiJ , . . . / — Zq such that Qp!<ZQ f z^, . . . ,z^> 

where cr. r :'I w — > T 
T g 

with derived input condition TRUE; 

(3) (Separability of P) the following formula is valid: 



[°E :x 0 = <x l' 



/X, 



n 



... jX^> € E <z 0 ,z 1 , ... f 

> A . P w . :< x ifZi> A °’'i ,: <Zi f • ♦ • ' z n > = Z g 



=*> 



P 

§ 



:<x 0 ,z 0 > ^ 



(4) (Solutions to Auxiliary Problems) for each s€S-£, f s satisfies 

II s = ^Eg/Tg, Jg f P s >; 



(5) (Structure of f ) 

§ 

(5.1) f :x = if 

§ 

q:x -» h:xO 
_q:x cr T *f w *ag:x 
fi 

(5.2) the guard ~q is K E , 

(5.3) h satisfies the specification <E , T , J / \q, P >, 

§ § § § 

(5.4) the following formula is valid: 

Vx6E [J :x Defined*q:x] ; 

§ § 

then the simple divide and conquer program F satisfies || . 

A 

Proof : lb show that F satisfies || we first show that f s satisfies JT S for each 

s € S. By condition (4) this is so for each s€S-£. lb show that f satisfies 

£ 

|| = <E ,T ,J ,P > we will prove 

£ £ £ £ £ 



Vx €E [J :x =£■ P:<x,f :x>] 

£ £ £ 

by structural induction-*- on E . 

£ 

1 Structural induction on a well-founded set <W, is a form of mathematical 
induction described by 

Vx€W Vy € W[x J-y A Q:y =» Q:x] =» Vx6W Q:x 
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Let x be an object in E such that J :x holds and Assume (inductively) that 

§ § 

J :y =» P:<y,f :y> holds for any y€E such that x^y. From J :x and condition 
g g g r g 

(5.4) it follows that q:x is defined thus there are two cases to consider: 
q:x = TRUE and ~q:x = TRUE. 

Case 1: Assume that q:x=TRUE then f :x=h:x by construction of f . Furthermore 
g g 

according to condition (5.3) we have J :x A q:x P :<x, h:x> from which we 

g g 

easily infer P :<x, h:x> or equivalently P :<x, f :x>. 

g g g 

Case 2; Assume that ~q:x = TRUE then f^:x = cr T -f w *cr E :x. We will show that 

P :<x,f :x> by using the inductive assumption and modus ponens on the separabil- 
g g 

ity condition. By condition (5.2) ~q is Kg so Kg:x=TRUE. Since J^:x also 

holds, and Og satisfies its specification in condition (1), the output condition 
of cr E also holds. Let <x E :x = <x lf . . . ,x n >. We have for each i €n J w> :x^. Con- 
sider Xj for each i€n. If w^ ^ g then by condition (4) we have J w> :x^ =¥ 
P w :<x^ ,f w . :x^> and we obtain by modus ponens P w :<x^ ,f w . :x^>. If on the other 

hand w^ = g then by condition (1) we have XqJ-xj and thus by our inductive 
assumption J w . :xj =¥ P w> :<x^,f w . :x^>. Again we obtain P w . :<x i ,f w . :x^ by modus 

ponens. By condition (2) we have Qj.:<o-,j.:<f w sx^, • • • ,f w :x n >,Zp . . . ,z n > where 

Om:<f, f :x n ,...,f, I :x r ,> = f :x. We have now established the antecedent of condi- 
1 W 1 1 w n n g 

tion (3) enabling us to infer P :<x, f :x>. 

g g 

We have shown that for each s€s f s satisfies || s = <E S ,T S ,J S ,P S >. It 
remains to show that F is a L-restricted homomorphism from E to T for some rela- 
tion L on E . Let L be Kg. If x€e and Kgtx holds then by condition (5.2) 
g g 

~q:x holds thus f :x = cr T *f w *Og:x. QED 



In overall structure the synthesis method systematically attempts to 
satisfy the conditions of Theorem 1 more or less in the stated order. Condi- 
tions (1), (2), and (3) are used to construct E and T. Condition (5.2) is used 
to determine q. Finally condition (5.3) is used to construct h. The various 
derived functions are assembled according to the schema in condition (5.1). 

i.e., if Q:x can be shown to follow from the assumption that Q:y holds for each 
y such that xj-y, then we can conclude that Q:x holds for all x. 
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3. 3 Design Method for Simple Divide and Conquer Algorithms 



The synthesis method described in this section constructs a simple divide 
and conquer algorithm along the lines suggested by Theorem 1. We first describe 
the method formally then provide a detailed explanation in Section 3.4 of the 
synthesis of a selection sort algorithm. The reader may find it useful to read 
the description and the example in parallel . 

Let TYPEBAG(A) be the bag of primitive data types whose product forms the 
data type A. For example, 

TYPEBAG ( ]N X (IN XLIST(]N))) = { ]N , W,LIST( W) } . 

Assume we are given a specification || =<D,R,I,0>. The following steps of the 
synthesis method produce a 2 - P r °bl em reduction representation || = <E,T,J,P> 
representing If. The first step is to find a suitable sort set S and signature 

2 - 



1. Determine a set of sorts S and a simple S-sorted signature 2 of type <w,§>. 

Che heuristic for determining S and 2 is as follows. Let a€TYPEBAG(D) and 
b € TYPEBAG (R) be primitive types which are the principal carriers of known alge- 
bras A and B respectively where A and B have the same simple signature. Let S 
be the sort set and 2 be the S-sorted signature of A and B. Types a and b will 
be called the recurrent types in D and R respectively. Intuitively the 
recurrent types correspond to those inputs and outputs which will be decomposed 
and composed respectively. The other inputs and outputs will remain unaffected 
by the decomposition and composition operators. 

For example, suppose D = U X LIST( ]N) and R = BAGS (IN). According to Example 
2.4.1 we have algebras with the same signature for LIST(]N) and BAG (IN) - in 
particular the sort set S is {§,c} and the signature 2 has type <c§,§>. We 
adopt 2 as the signature of the algebras to be constructed on D and R. 



2 . 



E 

§ 



Determine the component problems | 

Determining the principal problem 

= D, T = R, J I, P 4 => 0. 

§ § § 



I s = <E S ,T S , J S ,P S > for each s€S. 

|| is easy since we want IT = TT; i.e., 
§ § 

The structure of the auxiliary problems is 



based on the simplifying assumption that a simple known function satisfies each 
auxiliary problem (alternatives are discussed in Section 3.5). Accordingly, for 
each s€S-§, let E s = Ag and T s =Bg. We select a function f s from the DSKB such 
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that f s :E S -» T s , then let J s :x Defined*f s :x and P s :<x,z> <*=*> z = f £ :x. 

In the previous example we have sort set S= {§,c}, a signature with one 

operator of type <c§,§>, E = INXLIST(IN), T =Bag(]N) and algebras 

§ § 

A = <{ ]N ,LIST( ]N) } , {Cons}> and B = < { IN , BAG ( IN ) } , {Add } > . In these algebras 

A c = B C = IN, so we let E Q = T c = IN. The single operator cx E in E maps E^ into E°^ 

i.e., 

<t e : IN X LIST(IN) IN X ( IN X LIST( IN ) ) 

and the single operator cr T in T maps 1°® into T , i.e., 

cr T : IN X BAG (IN) -4- BAG (IN). 

Tb determine the auxiliary problem || c we retrieve a known function mapping E c 
to T c (IN to IN), such as the identity function Id. Then we can define I c :x <£=> 
TRUE (i.e.. Id is defined for all inputs) and P c :<x,z> <=» Id:x = z. 



3. Construct a well-founded ordering on E . 

§ 

Choose a known well-founded ordering on E^. If none is known then con- 
struct a well-founded ordering ^ on the recurrent type of E using Proposition 

§ 

1, then if necessary use Proposition 2 to make it into a well-founded ordering 

on E . 

§ 



4. Construct the operators of E and T. 

There are 2 alternate ways to finish the construction of E and T; in one we 
construct E then T, in the other we construct T then E. The important idea here 
is that once we construct the first operator we essentially "solve for" the out- 
put conditions of the other operator using the separability condition of Theorem 
1. In other words, the separability condition can be likened to an equation in 
several unknowns - after plugging in a value for all variables but one we can 
solve for the value of the one. The "unknowns" are the output conditions of the 
operators <x E , a T , and f £ for each s€s-§. 

In the following sequence, called track ET, we construct E then T. The 
difference between the two tracks is this: the input and output types of the 
operators have already been determined. Furthermore, condition (1) of Theorem 1 
predetermines some of the input and output conditions for Og. The only other 
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constraint on the operators is that they satisfy the separability condition. So 
in track ET we synthesize any function at all for cr E satisfying the input/output 
type and condition (1) of Theorem 1 which should be easy to do. The hard part 
is determining an output condition for cr T which satisfies the separability con- 
straint. We use the precondition engine to find such an output condition then 
form a complete specification for Op. Finally, a function is synthesized satis- 
fying this specification. In the other track, called track TE, an operator Op 
is synthesized satisfying a specification based on condition (2) of Theorem 1. 
we then derive an output condition for <x E required by the separability con- 
straint and use it to form a complete specification for cr E . Finally cr E is syn- 
thesized. 



ET 4.1 Construct E 

Construct a decomposition operator satisfying the specification 



°E :x 0 = < x l' * * *' x n> such that J § :x 0 ^ j£ n ( J Wj :x j A (Wj=§ =*> x Q }.Xj)) 



where ov-tE E 



,w 



with derived input condition K e :xq. The specification is constructed from con- 
dition (1) of Theorem 1 and the input/output types obtained from step 2. 
Included in the specification are all elements of the specification in condition 
(1) of Theorem 1 which are known at this point. After synthesizing the operator 
<t e we can define O e :<Xq,x^, . . . ,x n > to be o- e :xq = <Xj, . . . ,x n >. 

ET 4. 2 Construct T. 



ET 4.2.1 Derive the output conditions for Op. 
Find a {Zq,z^, . . . , z n ) -precondition Op of 



<z 0 /Zi, • • • , z^^ € T^ V ^Xq ,X p , . . * , Xp^ € 

[°E :x 0 = <x l' * * * , x n> A j'g'^Wj : < x j ,Zj> => P g :<x 0 ,z Q >] (ET 4.2.1) 

The derived precondition Op is an output condition needed by Op in order to 
satisfy the separability condition of Theorem 1. 



ET 4.2.2 Construct <jp. 
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Using the precondition Op from the previous step, we construct <x T according 
to the specification 

. . .,z n > = Zq such that C*p:<Zg,Zp, . . . ,z n > 
where <t t :T w T . 

This completes the description of track ET. We now present its alternate - 
track TE. 

Track TE - Construct T then E 
TE 4.1 Construct T 

Construct the operator <r T out of known functions according to the specifi- 
cation 



cr T :<Zp, . . . ,z n > = Zq such that TRUE 
where crr I ,:'I w -> T . 

All that we need to do here is to construct a mapping from T w to T^. This 

specification is based on the specification in condition (2) of Theorem 1. Once 
ovp has been synthesized we can define Okp:<Zg,Zp, . . . ,z n > to be 

(Tip !<Zp,..., Z^ > = Z q . 

TE 4.2 Construct E. 

TE 4.2.1 Derive output conditions for <x E . 

Find a {xg,Xp, . . . ,x n ) -precondition 0 E of 

V<x 0 ,x 1 ,...,x n >€ E w V<z 0 ' z l'*“' z n >€T§W 

^j'€n Pw j :<X j' Z j > A °T : < Z 1 # * * * ,z n > “ z 0 ^ P g :<x 0' z 0 >] (TE4.2.1) 

Taking 0 E as an output condition of <r E enables us to satisfy the separability 
condition of Theorem 1. 

TE 4. 2. 2 Construct E 

Construct the operator <r E according to the specification 
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°E :x 0 = <x l' * * * ,x n > such that J :x 0 ^ °E :<x o fX l'*" ,x n > A 

§ 

(A J w .:x i A (w i =§ =» x 0 yx,)) 

j €n j J J J 

where <x P :E -» E w 
E § 

with derived input condition K E :x. This completes the description of step 4. 



5. Determine the guard q. 

In accordance with condition (5.2) of Theorem 1 the guard ~q is simply 
taken to be the derived input condition K £ returned by the construction of <x E . 
We also attempt to verify condition (5.4) of Theorem 1 by deriving a {x}- 
precondition of 

Vx€e [J =¥ Defined*q:x] . 

§ § 

Let I^j be the derived precondition. If Kg is TOUE then condition (5.4) has been 
satisfied. Otherwise for legal inputs such that J^:x A K^ix it is possible 

that the guard q:x is undefined thus f^:x is undefined. We take a simplified 

form of J^:x A Kg:x as a new input condition and return to step 4. 

6. Construct the primitive operator. 

Construct an operator h according to the specification 

h:xg = z 0 such that Jg :x 0 A q:x 0 =¥ P^:<Xq,Zq> 

where h:E T . 

§ § 

with derived input condition 1^. 



7. Construct a new input condition if necessary. 

If h is unsatisfiable or if the derived input condition is not TRUE then 
we are not guaranteed that h will handle correctly all inputs which it may be 
required to handle. It is necessary then to revise the input condition and then 
go back and rederive the operators of E and T, the guards, and h in accordance 
with the new input condition. At this point we have effectively derived a pro- 
gram satisfying output condition P with input condition 

§ 

(J § ^ ~ q) V (J g A q A ^)- (3.3.1) 



We take a simplified form of (3.3.1) as the new input condition J and return to 

§ 
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step 4. In other words, formula (3.3.1) exactly describes the set of inputs 
which we know to have solutions thus we take it as our new input condition. 

8. Assembly of a divide and conquer algorithm. 

Assemble the functions derived above according to the schema 

f :x n = if 

q:x Q h:x Q 0 
~q:Xg -> 0Vp*f w *0g: x Q 
fi. 



The derived input condition on this program is J :x 



0 * 



3. 4 Synthesis of a Selection Sort Algorithm 
3.4.1 Synthesis of Ssort 

Suppose we are given the following specification for sorting a list of 
natural numbers 



Sort:x = z such that Bag : x = Bag : z A Orderedtz 
where Sort: LIST ( IN) LIST(IN). 

Hie input domains and output domains are both LIST(]N), the input condition is 
TRUE (i.e., there is none), and the output condition is Bag:x = Bag:z A 
Ordered :z. The steps of the synthesis method follow: 



1. Determine a set of sorts S and an S-sorted signature £. 

Since the input and output types are both LIST(IN) there is an easy choice 

of the recurrent type, namely LIST(]N). Several algebras are available in the 

D6KB with LIST(IN) as carrier; so suppose that we select A = <{ ]N , LIST ( IN ) } , 

{Cons}>. Ihe sort set of A is S = {c,§} where A =LIST(1N), A = IN, and the sig- 

§ c 

nature has type <c§,§>, i.e., Cons:A c ^ A . 

§ 

2. Determine the component problems. 

Let E = LIST ( ]N ) , T =LIST(]N), J <*=*> TRUE, P :<x,z> Bag:x = Bag:z A 

§ § § § 

Ordered:z. In order to determine the auxiliary problem <E C ,T C , J C ,P C > we first 
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set E c =T C =A C = ]N. We then look for a simple function from E c to T Q and select 
the identity function Id. Since Id is defined for all inputs we set 

J c :x 0 4=> TRUE 
P c :<x,z> <*=» z=Id:x x=z 

so that Id satisfies <E C ,T C , J C ,P C >. 



3. Construct a well-founded ordering on E . 

§ 

Suppose that we do not have a known well-founded ordering on E . By Propo- 

§ 

sition 1 we can construct one based on a mapping from E to ]N. Ihe known func- 

§ 

tion Length maps LIST(]N) to IN so define 

x 0 ^ x^ iff Length:xQ > Lengthix^. 

By Proposition 1 <E , }»> is a well-founded set. 

§ 



4. Construct the operators of E and T. 

Let us follow track TE and first construct T, then E. 



TE 4.1 Construct T 

Ihe specification for cr T is 

<x T :<b,z^> = Zq such that TRUE 
where ct t : IN X LIST (IN) -» LIST(IN). 

Ihe known function Cons has the same type as ct t and we easily conclude then that 



TE 4.2 Construct E 

TE 4.2.1 Derive the output specification of cr E 

Ihe output condition of cr E must satisfy the separability condition so we 
set up the problem of finding a {x 0 ,a,X 2 }-precondition of 

V<x 0 ,a,x 1 >€ LIST(IN) x IN X LIST(IN) V<z Q ,b,z 1 > € LIST( IN) X IN X LIST(IN) 

[ a = b A Bagrx^ = Bag:Zj A Orderediz^ A Cons:<b,Z 2 > = Zq 
=*> (BagiXQ = BagiZQ A Ordered :z Q )] 
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lb construct this formula we have made the following substitutions into the for- 
mula schema (TE 4.2.1): 

1. replace w by c§ 

2. replace E and T by LIST(]N) 

§ § 

3. replace E c§ and ^ by WXLIST(W) 

4. replace P c :<a,b> by a = b 

5. replace P :<x,z> by Bag:x=Bag:z A Orderedrz 

§ 

6. replace a T :<b,z 1 > by Cons:<b,Zj> 

In Figure 8 the precondition 

ajCBagix^ A Bag:x Q = Add:<a,Bag:x 1 > 

is derived. 

TE 4.2.2 Construct E 

Using the output precondition derived above, cr E is specified by 

cr E :x o = <a» x i> such that a^Bagrx^ A Bag:xg = Add:<a,Bag:xg> A 

Ijeng th : x g>Leng th : x ^ 
where cr E : LIST (U) ]NXLIST(W) 

In creating this specification we have simplified in certain ways: 1) since the 
input condition is TRUE it is omitted, 2) any conjunct which is TRUE is omitted, 
and 3) we replace Xg^x-^ by its definition. In Section 3.4.2 we derive a pro- 
gram satisfying this specification with derived input condition Xg/nil. For 
now we use the name Select in place of cr E and assume that it can be synthesized 
with derived input condition Xg^nil. 

5. Determine the guards. 

The guard ~q:Xg is simply the derived input condition x Q ^ nil required by 
Select. Consequently q:xg is Xg=nil. We must also verify that the guard q is 
defined on all inputs satsifying the input condition. To do so we seek a {xg}- 
precondition of 



Vxg € LIST ( IN) [TRUE =» Defined: (x Q = nil) ] 
which is easily shown to be TRUE. 
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Hypotheses: hi. a=b 

h2. Bag:xj = Bag:z^ 
h3. Ordered szj 
h4. Cons:<b,z 1 > = Zq 

Variables: {xQ/a/X^} 

Goal 1: <Q1> Bag :x Q = Bag :z Q 

R5 +h4 

<Q1> Bag:x 0 = Bag:Cons:<b,Z 2 > 

R5 + L8 

<Q1> Bag:x Q =Add:<b,Bag:z 1 > 

R5 + h2,R5 + hi 

<Q1> Bag:x Q = Add:<a,Bag:x 1 > 

P2 

where Q1 is Bag:XQ = Add:<a,Bag:Xi> 



Goal 2: 



<Q2> Ordered :Z q 
R 5 + h4 

<Q2> Ordered: Co ns :<b,Zj> 




<Q2> a^Bag^ 

P2 

where Q2 is a£Bag:x 2 

Figure 8: Derivation of the output condition of Select 



6. Construct a primitive operator. 

The specification for the primitive operator is 
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h:x 0 = z 0 such that x Q = nil =» (Bag :x Q = Bag :z Q A Ordered :z Q ) 
where h:LIST(]N) -» LIST(IN) 

To create this specification from the specification schema for h in Section 
3.3 we made the same substitutions as in step 4 plus the substitution of x Q = nil 
for qQ. When attempting to match known functions against a specification such 
as h the simplest functions are tried first. In this case the simplest of all. 
Id works. Proposition 4 can be used to verify that Id satisfies h. 

7. Construct a new input condition. 

In step 6 we found that Id satisfies the specification for h so no action 
is required here. 

8. Assembly of divide and conquer algorithm. 

Putting together all of the operators derived above, we obtain the follow- 
ing selection sort program: 

Ssort:XQ = if 

Xq = nil -» Xq 0 

Xq ^ nil -> Cons* (Id X Ssort) *Select:xQ 
fi 

The derived input condition on Ssort is TRUE. 



3.4.2 Synthesis of Select 

In the previous section we derived the specification 

SelectiXQ = <a ,x^> such that Bag :X q = Add :<a ,Bag :x^> A a_<Bag:x^ A 

Length:xQ > Lengthrx^. 
where Select: LIST (]N) -» IN X LIST (IN) 

Intuitively, Select:xQ splits Xq into two components, a and x^, such that 
together a and x^ have the same elements as Xq and furthermore a is no greater 
than any element of x^. Note that Select as specified has no input condition. 
However, for input nil the function is undefined. We will derive Xq X nil as an 
input condition of Select. The synthesis of Select proceeds as follows: 
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1. Determine a sort set S and signature 2 

The input type is LIST(IN) and the output type is ]N X LIST( U) . We select 

LIST(IN) as recurrent type in both and again choose algebra 

A = <{ 1N,LIST(IN) }, {Cons}> in which LIST(]N) is the principal carrier. As above 

the sort set is S={c,§}, A = IN, A =LIST(IN) and the single operator symbol 

^ § 

has the type <c§,§>. 



2. Determine the component problems. 



P 

§ 



Let E = LIST ( IN ) , T 
§ § 

:<x 0 ,<a,x 1 » Bag :Xg 



= IN X LIST(IN) , J :x n TRUE, and 
§ u 

= Add:<a,Bag:x 1 > A a£Bag:x 1 A LengthiXg 



> Length x^ 



Let E„ = A„ = IN and T = A = IN. Next we select a known function f_ mapping E_ to 

C C C C o 

T c and again Id is the simpliest choice. Let J c :xg be TRUE and P c :<Xg,x 1 > be 
Xq = IdiXj or simply x Q = x^. 



3. 



Construct a well-founded ordering on E 



E = LIST( IN) is made a well-founded set exactly as in the previous example 
§ 

by defining Xq^x^ iff LengthiXg > Lengthsx^. 



ET 4. Construct the operators of E and T. 

In this example let us construct E first then T. 

ET 4.1 Construct cr E 

The decomposition function for Select must satisfy the incomplete specifi- 
cation 



cr E ; Xo = <UfXi> such that LengthiXg > Length:x^ 
where cr E : LIST (IN) IN X LIST( IN) . 

This specification has been constructed according to the specification schema in 
step ET 4.1 of the synthesis method. We show only the simplified result. In 
constructing this specification we have omitted the input condition (since it is 
TRUE) and various output conditions which are TRUE. This practice will be fol- 
lowed in the sequel. A function structure is needed here and Proposition 4 can 
be used to show that [First, Rest] satisfies cr E with derived input condition 
XgXnil. First, the input and output domains of [First, Rest] are identical to 
that for cr E . By Axiom L6 we have x X nil as the domain of definition of 
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[First, Rest] . In terms of Proposition 4 then we have: 

I x : x o / Xq / nil 

I 2 ;x 0 ^ TRUE 

0 2 ; <x 0 /< u,x i» ^ Length:x Q > Lengthrx^. 

According to condition (d) of Proposition 4 we derive a {xQ}-precondition of 

Vx 6LIST(]N) [TRUE =* x Q ^ nil] 

which is simply Xq ^ nil (called J in Proposition 4). Finally, according to con- 
dition (e) of Proposition 4, we derive TRUE as an [x 0 }-precondition of 

Vx q €LIST(]N) V<u,x 1 >€ ]N X LIST(IN) 

[x 0 ^nil A TRUE A [First, Rest] :x Q = <u,x^> =#> Length:x Q >Length:x^] . 

in Figure 9. Ihus by Proposition 4 [First, Rest] satisfies <r E with derived input 
condition x Q ^nil A TRUE, or simply x Q ^nil. 

ET 4.2 Construct T. 



Hypotheses: hi. x Q ^ nil 

h2. [First, Rest] :X q = <u,x^> 
h3. u = First:x Q 
h4. X2=Rest:xQ 

Variables: {x Q } 

Goal 1: <TRUE> Length :X q > Length :x^ 

| R6 + h2 + L7 

<TRUE> Length*Cons:<u,X 2 > > Length:x^ 

| R5 + L15 

<TRUE> 1 + Length:x^ > Lengtinx^ 

| R3+nl 
<TRUE> 1 > 0 
PI 

Figure 9: Matching [First, Rest] with specification for cr E . 
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ET 4.2.1 Derive the output condition of <r T . 

Ihe output condition of must satisfy the separability condition so we 
seek a [ag^Q^a^z^J-precondition of 

V«a 0 ,z 0 >,v,<a 1 ,z 1 »6 W XLIST(W)) X W X (U X LIST(W) ) 

V<x 0 ,u,x 1 >6 LIST(W) X W X LIST(U) 

[ [First, Rest] :Xg = <u,X2> A u = v A Bagsx-j^ = Add:<a 1 ,Bag:z 1 > A a-^^Bagiz^ A 
Lengthrx^ > Lengthrz-^ =» 

(Bag:x 0 = Add:<a Q/ z 0 > A a Q _<Bag:z 0 > A Length:x Q > Length:Zg)]. 

To create this formula the following substitutions were made on the formula 
schema in step ET 4.2.1 of the synthesis method: 
eg replaces w 

E =LIST(]N) and T -WXLIST(W) 
g g 

E C =T C = ]N 

[First, Rest] replaces cr E 
Id replaces P c 

Bag:x^ = Add:<a^,Bag:z^> A a^j<Bag:z^ A Lengthix-^ > Lengthrz-^ 
replaces P^:<X£,z^> 

In Figure 10, the precondition 

a^Bag^j. =» Add:<v, Add :<a lf Bag :z 1 » = Add :<a Q ,Bag :z Q > A 
a 0 <Bag:z 0 A 2 + Length:z 1 >Length:z Q 



is derived. 

ET 4.2.2 Construct <Xj,. 

We construct the specification 

cr T :<v,<a 1 ,z 1 » = <a 0 ,z Q > such that a^Bag^ =$> a 0 <Bag:z Q A 
Add:<v, Add:<a 1 ,Bag:z 1 » = Add:<a 0 ,Bag:z 0 > A 2 + Length:z 1 > Length:z Q 
where cr T : H X (W X LIST(W)) -> U XLIST(]N) 

A conditional program, call it Compose, can be constructed satisfying this 
specification with derived input condition TRUE: 
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Hypotheses : 


hi. [First, Rest ] :xq = <u,Xj> 
h2. Bagsxj = Add:<a 1 ,Bag:z 1 > 
h3. ^ < Bagsz^ 
h4. u = v 

h5. Lengthrx^ > Length:z^ 


Variables: 


^ a l /Z l' v ' a 0' Z 0^ 


Goal 1: 


<Q1> Bag:x Q = Add:<a 0 ,Bag:z Q > 

R6 + hi + L7 

<Q1> Bag:Cons:<u,x 1 > = Add:<a 0 ,Bag:z 0 > 

R5 + L8 

<Q1> Add:<u,Bag:x2> = Add:<aQ,Bag:zQ> 

R5 + h4, R5 + h2 

<Q1> Add:<v,Add:<aj L ,Bag:Zj L » = Add:<ag,Bag:zQ> 

P2 

where Q1 is Add:<v,Add:<a 1 ,Bag:z 1 » = Add:<a 0 ,Bag:z 0 > 


Goal 2: 


< a O<Bag:Zo> a 0 <Bag:z 0 
P2 

Figure 10a: Derivation of output conditions for cr T . 
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Goal 3: <Q2> Length :x Q > Length :z Q 

|R6 +hl +L7 

<Q2> Length:Cons:<u,x^> > LengthiZQ 

R5 + LI 5 

<Q2> 1 + Lengthrxj > LengthrZg 

R6 +h2 + L19 

<Q2> 1 +Card:Add:<a 1 ,Bag:z 1 > > Length:z Q 

| R5+B6 

<Q2> 1 + 1 +Card:Bag:z 1 > Length:z Q 

| R5 + L18 

<Q2> 1 + 1 + Length :z ^ > Length:z Q 

P2 

where Q2 is a^^^BagrZj^ => 1 + 1 + Lengthiz-^ > Length:z Q 
Figure 10b: Derivation of output conditions for Oj.. 



Compose : <v , <a z 



if 

v <a± -» <v,Cons:<a 1 ,z 1 »D 
v^a^ <a-^,Cons:<v,Z2» 
fi 



5. Determine the guards. 

The input condition derived for Og is x 0 ^ nil which we take as ~q:Xg. Tb 
verify condition (5.4) of Theorem 1 we easily prove that ~q is defined on legal 
inputs. However, we noted before that Select will be undefined when its input 
is nil, yet here we are about to use the guard Xq = nil on the primitive opera- 
tor. The next step will reveal the need for revision of the input condition. 

6. Construct a primitive operator. 

The specification of the primitive operator is 
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h:x 0 = <a,Xi> such that x Q = nil =3> Bag:x Q = Add:<a,Bag:x 2 > A 
a^Bagzx^ A Length:x 0 > Lengthtx^ 
where h: LIST (U) IN X LIST ( IN ) . 



It is easily shown that this specification is unsatisf iable. 

7. Construction of a new input condition. 

Since the specification for the primitive operator is unsatisf iable we form 
a new input condition by constructing and simplifying the expression 

(TRUE A ~( x 0 = nil) ) V (TRUE A x Q =nil A FALSE) 

yielding XQ^nil. In effect we exclude nil as a legal input to Select and 
return to an earlier stage in the synthesis and rederive erg, cr T , and q. In the 
following we retrace some of the previous steps: 



4'. Construct E then T. 



The input condition J :x 



0 



is redefined to be Xp^nil. 



ET 4.1' Construct Og 

The new specification for Og is 

(TgSXQ = <U/ X i> such that x Q ^ nil =¥ Length :x Q > Length.-x^ A x^ ^ nil 
where a E : LIST (IN) -> IN X LIST( IN) . 

We found that [First, Rest] satisfied the earlier specification for Og so it is 
reasonable to try it again. This time we have (in terms of Proposition 4) 

I l :x 0^ x 0 ^ 

I 2 : x 0 < ^ x 0 ^ n * 1 

02 :<x 0 ,<a,Xj!»<=^ (Length:xg > Lengthix^ A x^^nil) 

In satisfying condition (d) of Proposition 4 we derive TRUE as an {xq}- 
precondition of 

Vx 0 € LIST( IN) [x Q ^ nil =* x Q t* nil] . 

In satisfying condition (e) we set up the problem of finding an {xq}- 
precondition of 

Vxq€LIST(IN) VO/X 2 >€lNX LIST(IN) [xQ^nil A a=First:x Q A Xi=Rest:x 0 
=> Length:x 0 > Lengthix^ A x^Xriil]. 
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The precondition Rest:x 0 ^nil is derived in Figure 11. By Proposition 4 
[First, Rest] satisfies cr E with derived input condition Rest:x Q ^nil. 

ET 4.2'. Construct T. 

This step does not involve the input condition so the derivation of ct t 
proceeds as before - we synthesize the conditional program Compose. 

5'. Determine the guard. 

The derived input condition on ct e is RestrxQ^nil thus q:xp is 
Rest:xQ=nil. In Figure 12 we verify that q is defined when the input condition 
(xQ^nil) holds by deriving TRUE as a {xq} - precondition of 

Vxq€liST(]N) [xp^nil =¥ Defined : (Rest :x Q = nil) ] . 

6'. Construction of a primitive operator. 

The new specification for the primitive operator is 



Hypotheses: hi. Xp^nil 

h2. First:xQ=a 
h3. Rest:xQ=x^ 

Variables: {xq} 

Goal 1: <TRUE> Length:xQ > Lengthy 

(see derivation in Figure 9) 



Goal 2: 



<Rest:xQ f nil> x^ ^ nil 
R5 + h3 

<Rest:xQ ^ nil> Rest:xp^nil 
P2 



Figure 11: Matching [First, Rest] with specifications for a £ . 



lypotheses: hi. x Q ^nil 
/ariables: {} 



k>al 1: 



<TRUE> Defined : (Rest :xq = nil) 




<TRUE> Def ined :Rest:x 0 
| R3 + L5 
<TRUE> Xq X nil 
PI + hi 



<TRUE> Defined :nil 



PI + L1 



Figure 12: Verifying the guard in Select 



h:xQ = <a,x 1 > such that Rest:xQ=nil => Bag :Xq = Add :<a,Bag :x^> A 
a^Bagrx^ A Length :x Q > Length :x^ 
where h: LIST (IN) -> ]NXLIST(]N). 

lie function structure [First,Rest] is easily found to satisfy this specifica- 
:ion as follows: Again in terms of Proposition 4 we have: 

: 2 :xq 4=> Rest:x Q = nil 

i 2 :<XQ,<a,x 1 » 4=> Bag:xQ = Add:<a,Bag:x 1 > A 
a^Bag^ A Length :x Q > Length :xj 

^Xq 4=> XQ^nil (by Axiom L6) 

o satisfy condition (d) of Theorem 1, TRUE is derived as an {x 0 }-precondition 
f 



i Figure 13. Finally, to satisfy condition (e) , we set up the problem of find- 
ig a {Xq} - precondition of 

’'<x 0 ,<a 1 ,x 1 »€ LIST(IN) X ( IN X LIST(IN)) 

[■RUE A Rest:x 0 = nil A First:x Q =a^ A Rest:x 0 = X2 
$ Bag :xq = Add:<a,Bag :x^> A a£Bag:Xj A Length:xQ > Length:x^]. 

le precondition TRUE is derived in Figure 14. Finally by Proposition 4 we 



Vx € LIST (IN) [Rest :x Q = nil =» x Q Xnil] 
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Hypotheses: hi. Rest:xQ=nil 
Variables: {} 

Goal 1: <TRUE> x Q ^nil 

| R3 + L5 
<TRUE> Defined* Rest :xg 
R5 + hi 

<TRUE> Defined :nil 
PI + LI 

Figure 13: Matching [First, Rest] with the specification for h. 
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Hypotheses: hi. Rest:xQ=nil 

h2. [First/Rest] :x 0 = <a,x^> 
h3. First:x Q = a 
h4. Rest:xQ=Xj 

Variables: {xq} 

Goal 1: <TRUE> Bag:x 0 = Add:<a,Bag:xi> 

R6 + h2 + L7 

<TRUE> Bag:Cons:<a,x 1 > = Add:<a,Bag:x 2 > 

R5 + L8 

<TRUE> Add:<a,Bag:x 1 > = Add:<a,Bag:x 2 > 

PI +B1 

2. <TRUE> a^Bag^ 

R5 + h4 

<TRUE> a £ Bag :Rest:xQ 
| R5 + hl 
<TRUE> a £ Bag: nil 
| R5 + L20 
<TRUE> a <0 
PI +B2 

Goal 3: <TRUE> Length :X q > Length :x^ 

| R6+h2 + L7 

<TRUE> Length :Cons:<a,X 2 > > Length :x^ 

R5 + L8 

<TRUE> 1 + Lengthy > Length^^ 

R3 +nl 

<TRUE> 1 > 0 
PI 

Figure 14: Verifying the match of [First, Rest] with h. 



conclude that [First, Rest] satisfies h with derived input 
Rest:x 0 = nil A TRUE A TRUE or simply Rest :x Q = nil. 



condition 
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7'. Derivation of a new input condition. 

Since we constructed an operator satisfying specification h this step is 
bypassed . 

8'. Construction of a divide and conquer algorithm. 

The functions derived above are assembled into the following program: 

Select:xQ = if 

Rest:xQ=nil -» [First ,Rest] :xg Q 

Restsxg^nil Compose* (Id X Select) • [First, Rest] :xq 
fi 



The derived input condition on Select is x Q ^ nil 




The complete selection 



sort program synthesized in the above examples is listed in Figure 15. 



Ssortrxg — if 

Xq = nil -» Xq D 

Xg^nil -» Cons* (id X Ssort) ‘Select :xq 
fi 

Select:x = if 

Rest:x=nil -> [First,Rest] :x Q 

Rest:x / nil -» Compose* (Id X Select) • [First,Rest] :x 
fi 

Compose :<vp<V 2 »z» = if 

v l£ v 2 *■> <V2/Cons:<V2/Z» Q 

v l2. v 2 <^2 ,Cons:<v l fZ>> 
fi 

Figure 15: A Selection Sort Program 
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3. 5 Remarks on the Synthesis Method 



For the sake of simplifying the presentation we have placed a number of 
restrictions on the synthesis method. First, we only consider algebras E and T 
with a single operator, thus the term "simple divide and conquer algorithms". It 
is not hard to relax this constraint but the analogue of Theorem 4 becomes more 
complex. Second, we assume that the auxiliary problems are simply solved by 
primitive functions in the target language. A design method can be devised 
which allows the synthesis of nonprimitive auxiliary functions in the following 
way. The essence of the design method in Section 3.3 is the use of the separa- 
bility condition to solve for the output conditions of either <r E or cr T . We use 
it to set up a precondition problem by assuming simple solutions for the auxili- 
ary problems and for, say, <x E , then we derive output conditions for a T . The 
separability condition of Theorem 1 can be likened to a linear equation in 
several variables. We plug in simple values for all but one variable x then 
solve for x. We could just as well plug in simple decomposition and composition 
operators and solve for the output conditions of the auxiliary problems. Third, 
lie assume that there is only a single recurrent type: i.e., that only one of the 
parameters to a divide and conquer algorithm will be decomposed. It is not hard 
to relax this restriction however the decision about which parameters to decom- 
pose is not well -motivated at present (relying on rather weak heuristics). 

We now relate our synthesis method with previous work on deductive program 
synthesis. Suppose the user supplies a specification || =<D,R,I,0>. The deduc- 
tive approach to program synthesis [16,17,4] seeks to extract a program f from a 
instructive proof of the theorem 

Vx€D 3 z €R [I:x =4> 0: <x,z>] (3.5.1) 

theorem proving techniques, more or less adapted to the special demands of pro- 
gram synthesis, are used to prove the theorem constructively. We advance this 
approach in two ways. First, our definition of the program synthesis problem is 
slightly more general. We seek to extract a program f from a constructive 
terivation of an {x} -precondition of (3.5.1). The resulting precondition is the 
derived input condition. With this approach it is easier to create specifica- 
:ions because we are no longer required to completely specify the input condi- 
:ion. It also facilitates top-down problem decomposition because the decom- 
position process is not obliged to create complete specifications for subprob- 
.ems. Second, rather than rely on general theorem proving techniques we 
unphasize the use of special purpose program synthesis-oriented techniques. 
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specifically the design methods. The design method for simple divide and con- 
quer algorithms is based on Theorem 1 but it also embodies the procedural 
knowledge needed to apply it. Viewed as a theorem proving tool it seeks to 
exploit special structure in the specification. Specifically, it seeks to 
decompose the problem structure with respect to the separability condition of 
Theorem 1. We are currently developing analogous design methods for other 
classes of algorithms. 
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4. Further Examples 



In this section we derive three other sorting algorithms whose structure is 
that of divide and conquer. These algorithms are all constructed from the same 
specification but their design diverges when distinct choices are made at cer- 
tain steps in the synthesis method. 

4. 1 Synthesis of an Insertion Sort 

4.1.1 Synthesis of Isort 

The synthesis of an insertion sort and a selection sort are similar. The 
synthesis process diverges at Step 4 - the selection sort follows track TE, 
insertion sort follows track ET. Intuitively, selection sorts make use of a 
simple composition operator and a somewhat complex decomposition operator 
whereas insertion sorts make use of a simple decomposition operator and a com- 
plex composition operator. Again the initial specification for sorting a list 
of natural numbers is 

Sort:x = z such that Bag : x = Bag : z A Orderedrz 
where Sort:LIST( IN) LIST(]N). 

Isort is synthesized as follows with some details omitted for brevity. 

1,2,3. Determine a sort set, signature, component problems, and a well-founded 
ordering. 

As in Ssort let S= {c,§}, let 2 be a simple S-sorted signature of type 

<c§,§>. and let E =LIST(]N), T =LIST(]N), J :x <=> TRUE, and P :<x,z> 4=> 

§ § § § 

Bag:x=Bag:z A Ordered z. 

Also let E c = ]N , T c = IN, f c :x=x, and thus again J c :x <=> TRUE, P c :<x,z> 
\ / x — z • 

Define Xq^x^ by Length:xQ>Length:x^. 

At step 4 the synthesis process follows track ET. 

ET 4.1 Construct E. 

The decomposition operator <x E for Isort has the specification 
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°E :x 0 = < a ' x i> suc ^ that Length :xg>Length:x 2 
where cr E : LIST (]N) ]N X LIST ( IN ) . 

In constructing this specification we have omitted the input condition 
since it is TRUE and various output conditions which are TRUE. 'Ihis practice 
will be followed in the sequel. The construction [First, Rest] is easily shown 
to satisfy this specification with derived input condition x Q Xnil. (See the 
analogous matching process in Figure 9) . 

ET 4.2 Construct T. 

ET 4.2.1 Derive output conditions of cr T . 

The output condition of <r.p is obtained by deriving a {Zg,b,Zi}-precondition 
of 

V<z 0 ,<b,z 1 »€ LIST(W) X (IN X LIST ( IN ) ) V<x Q ,<a,x 1 » € LIST( Dl) X (3N X LIST(]N)) 
l [First, Rest] :xq = <a,Xj> Aa = b A Bag :x^ = Bag :z^ A Ordered :zj 
=> Bag:xg = BagsZg A Ordered :Zq], 

The precondition 

Ordered:z^ Add:<b,Bag:z 2 > = Bag:Zg A Ordered:zg 
is derived in Figure 16. 

ET 4.2.2 Construct T 

Using the precondition derived in the previous step we create the specifi- 
cation 

o- T :<b,Zi> = Zq such that Ordered:z^ =£> Add:<b,Bag:z 1 >=Bag:Zg A OrderediZg 

where o^: ]N X LIST(]N) -» LIST(]N). 

A program called Insert is synthesized in the following section which satisfies 
-this specification. 

5. Determine the guard. 

The guard ~q:xg is simply the derived input condition Xq X nil on cr E . Tb 
verify that q is defined on legal inputs we easily can show that 

Vx € LIST (W) [TRUE =» Def ined : (x = nil) ] 
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Hypotheses: hi. [First, Rest ] :xq = <a,xi> 

h2. a = b 

h3. Bag:x^ = Bagsz-^ 
h4. Ordered :z^ 

Variables: {b,ZQ,z^} 

Goal 1: <Q> Bag :x Q = Bag :z Q 

R6 + hi + L7 
<Q> Bag : Cons : <a, x^> = Bag: Z q 

R5 + L8 

<Q> Add :<a ,Bag :x> = Bag :Z q 
| R5 + h2 

<Q> Add:<b,Bag:z^> = Bag:Zg 
P2 

where Q is Ordered^^ =r> Add:<b,Bag:z^> = Bag:Zg 

Goal 2: <Ordered:zi =» Ordered :Z q> Ordered :Z q 

P2 

Figure 16: Derivation of CXitput Conditions for the Composition Operator of Isort 



is valid. 

6. Construct the primitive operator. 

The primitive operator has specification 

h:x Q = z Q such that Xg = nil =£> (Bag :Xg = Bag :Zg A Ordered :Zg). 
where h: LIST (W) LIST(W). 

As in the synthesis of Ssort we can show that Id satisfies h. 

7. Construct new input condition. 

Since we constructed an operator satisfying the specification for h this 
step is bypassed. 
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8. Construction of the divide and conquer algorithm. 

Putting together the operators derived above we obtain 

Isortrx = if 

x = nil -» x 0 

x^nil Insert* (Id X Isort) • [First, Rest] :x 
fi. 

The derived input condition on Isort is simply TRUE. 



4. 1. 2 Synthesis of Insert 

The following specification for Insert was derived in the preceeding sec- 
tion 

Insert: O q,Xq> = Zq such that Ordered:xQ =*► Bag:ZQ=Add:<aQ,Bag:xg> A OrderedrZg 

where Insert: U X LIST( ]N) LIST(IN). 

The task of Insert is to place a number in an ordered list such that the result- 
ing list is ordered. The synthesis of Insert proceeds as follows. 

1.2 Determine a sort set, signature, and component problems. 

Choices like those made in Ssort, Select, and Isort can be made here for 
Insert with the result S = {c,§}, £ is a simple S-sorted signature of type 
<c§,§>, 

E g = MX LIST(IN) 

T = LIST( ]N ) 

§ 

J^:<ag,Xg> <=$> Ordered :Xq 

:«aQ,XQ>,Zg> 4 =$ Bag:Zg = Add:<ag,Bag:xQ> A Ordered:xg, 

E c = ]N , and T c = IN . 

Again we find Id:E c T c so let 
J c <=» TRUE, 

^c : ^ a l , ^ > ' > '' ^ a^ = b, and 
f c - Id. 

3. Determine a well-founded ordering on E^. 
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Using Propositions 1 and 2, we can construct a well-founded ordering on the 
input type HXLIST(]N) defined by 

< a 0' x 0> ^ < a l ,x l> iff Length:x 0 > Lengthix^. 

TE 4. Construct T then E 

TE 4.1 Construct T. 

The composition operator of Insert has partial specification 

a T :<b f z 1 > = z Q such that TRUE 
where cr T : ]N X LIST (]N) -» LIST(]N) 

The primitive operator Cons is easily shown to satisfy this specification. 

TE 4.2 Construct E. 

TE 4.2.1 Derive output conditions for Og. 

The output conditions of cr E are found by deriving a {a 0 ,XQ f a 1 ,a 2 »x 2 }- 
precondition of 

V«a 0 ,x 0 > f a lf <a 2 ,x 2 »€ ( ]N X LIST(M)) x W x ( W X LIST(]N)} 

V<z 0 ,b,z 1 >€ LIST(IN) X JN X LIST ( ]N ) 

t a l = b A Bag:zj =Add:<a 2 ,Bag:x 2 > A Orderedsz^ A Cons:<b,Zi> = z Q 
=> Bag:z Q = Add :<a 0 ,Bag :xq> A Ordered :zq]. 

The derivation in Figure 17 yields precondition 

Add:<a lf Add:<a 2 ,Bag:x 2 » = Add:<a 0 ,Bag:x 0 > A a i <. a 2 A a 1 £Bag:x 2 . 

TE 4.2.2 Construct E. 

We construct specification 

cr E :<aQ,XQ> = <a^,<a 2 ,x 2 » such that Length :xQ>Length:x 2 A 
Add:<a 1 ,Add:<a 2 ,Bag:x 2 » = Add:<a 0 ,Bag:x Q > A a i £ a 2 A a^<_Bag:x 2 
where cr E : ]N X LIST (]N) ]N X (1* X LIST(W) ) . 

A simple conditional program called Decompose is easily constructed according to 
this specification with derived input condition Xg^nil: 



- 69 - 



Hypotheses: hi. a^=b 

h2. Bag:z-j=Add:<a 2 , Bag:x 2 > 

h3. Ordered :z^ 

h4. Cons:<b,Zi> = Zq 

Variables: {aQ,XQ,a 1 ,a 2 ,x 2 } 

Goal 1: <Q> Bag:z Q = Add :<a Q ,Bag :X q> 

R5 +h4 

<Q> Bag: Cons :<b,z^> = Add :<aQ,Bag :xq> 

| R5 + L8 

<Q> Add:<b,Bag:z^> = Add:<aQ,Bag:xQ> 

| R5 + h2 

<Q> Add:<a i ,Add:<a 2 ,Bag:x 2 »=Add:<a 0 ,Bag:xQ> 

P2 

where Q is Add:<a 2 ,Add:<a 2 ,Bag:x 2 »=Add:<aQ,Bag:xQ> 



Goal 2: 



<Q3> Ordered :Z q 

R5 + h4 

<Q3> Ordered :Cons:<b,Z 2 > 

R3 + L12, R1 




<Q3> b£Bag:z 2 <TRUE> Ordered :z^ 

R5 + hl, R5+h2 Pl+h3 

<Q3> a^ £Add:<a 2 ,Bag:x 2 > 

A " R3 + B3, R1 



<Q1> a 1 <a 2 <Q2> a 1 <Bag:x 2 

P2 P2 

where Ql is a^ < a 2 , Q2 is a^£Bag:x 2 and Q3 is Ql A Q2 



Figure 17: Derivation of Output Conditions for Decomposition Operator in Insert. 
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Decompose :<aQ,XQ> — if 

a 0 £First:xQ -> <a 0/ <First:xQ,Rest:x 0 » 0 
a Q >First:x Q <First:x 0 ,<aQ,Rest:x 0 » 
fi. 

5. Determine the guard. 

The input condition on cr E is Xq X nil thus q:x Q <*=» XQ = nil. Ib verify that 
q is defined whenever the input condition holds we easily prove that 

V<a,x>€ ]N X LIST(IN) [ Orderedrx =» Def ined : (x = nil) ]. 

6. Construct the primitive operator. 

The primitive operator must satisfy 

h:<aQ,XQ> = ZQ such that x 0 =nil A Ordered :X q 
B ag:z 0 = Add:<aQ,Bag:xQ> A Ordered:z Q 
where h: ]N X LIST (]N) -» LIST(]N). 

It is easily shown that the operator Cons satisfies this specification. 

7. Construction of a new input condition. 

Since Cons has been found to satisfy the specification h this step is 
bypassed . 

8. Final assembly of the divide and conquer algorithm. 

Putting together the operators derived above we obtain 



Insert:<aQ,XQ> — if 

x Q =nil Cons:<a 0 ,XQ> 0 

XQ^nil -» Cons* (Id X Insert) *Decompose:<aQ,XQ> 
f i . 

with derived input condition TRUE. The completed insertion sort algorithm Isort 
is given in Figure 18. 
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Isort:x 



if 



x = nil x D 

x^nil Insert* (Id X Isort) • [First,Rest] :x 



Insert:<a,x> — if 

x=nil -» Cons:<a,x> 0 
x ^ nil -> Cons* (Id X Insert) ‘Decompose :x 
fi 



Decompose :<a 0 ,XQ> — if 

a 0 _<First:x 0 -> <a 0 ,<First:xQ,Rest:x 0 » 0 
a o2.First:xQ <First:xQ,<aQ,Rest:xQ» 

fi 



Figure 18. Complete Insertion Sort Algorithm 



4. 2 Synthesis of a_ Merge Sort Algorithm 

4.2.1 Synthesis of Msort 

Again we start with specification 

Sort:x = z such that Bag :x = Bag :z A Ordered:z 
where Sort: LIST(U) LIST(M). 

The synthesis of a mergesort (and a quicksort) distinguishes itself from Isort 
and Ssort immediately in the choice of signature. 

1. Choose a sort set and signature. 

As before LIST(]N) is the only choice for recurrent type on both the input 
and output domains. Suppose however we choose the algebra 
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B = < { LIST ( JN ) } , {Append } > which has sort set S= {§} and a simple S-sorted signa- 
ture of type <§§,§>. I.e. f Append :B XB B . 

g g g 

2. Determine the component problems. 

Let E = LIST(IN), T =LIST(]N) f J = TRUE, and P : <x,z> <*=$> Bag:x=Bag:z A 

g g g g 

Ordered :z. There are no auxiliary problems. 

3. Determine a well-founded ordering on E . 

g 

Again we define Xq^-x^ by Lengthrxg > Lengthrx^ as an appropriate well- 
founded ordering by Proposition 1. 

ET 4. Construct E then T. 

Mergesort differs from quicksort in following track ET rather than TE. In 
other words mergesort, like insertion sort, uses a simple decomposition operator 
and a complex composition operator whereas the reverse holds for quicksort. 

ET 4.1 Construct E. 

After instantiating and simplifying the schematic specification in step ET 
4.1 of the synthesis method we obtain 

cr E :x 0 = < x i' x 2> suc h that Length :x 0 >Length:xi A Length:x 0 >Length:x 2 
where a £ : LIST (IN) -» LIST( ]N ) X LIST( ]N) . 

In Example 3.1.1 we showed that the primitive operator Listsplit satisfies this 
specification with derived input condition Length:xQ>l. 

ET 4.2 Construct T. 

ET 4.2.1 Derive output conditions for o^. 

The output condition of the composition operator is found by deriving a 
{zQ,Zi,z 2 }-precondition of 

V<z 0 ,z 1 ,z 2 >€ LIST(IN) XLIST(IN) XLIST(IN) 

V<x 0 ,x 1 ,x 2 >€ LIST(W) XLIST(W) XLIST(W) 

[Length : x^ = Length :X q div 2 A Length:x 2 = (1 + Length:x Q ) div 2 A 
Append :X q = <x^,x 2 > A Length :x 0 >Length:x^ A Length: x 0 >Length:x 2 A 
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Bagix^ = Bagsz^ A Orderediz^ A Bag:x 2 = Bag:z 2 A Ordered:z 2 
=» Bag :xq = Bag :Zg A Ordered :z Q ]. 

The precondition 

Ordered :z^ A Ordered :Z 2 =£■ (Union:<Bag :ZpBag :Z 2 > = Bag :Zq A Ordered :Z q) 
is derived in Figure 19. 

ET 4.2.2 Construct T. 

Instantiating the above output condition in the schema ET 4.2.2 we obtain 
the specification 

ct t :<z 1 ,Z 2 > = z Q such that Orderedrz-^ A 0rdered:z2 
Union: <Bag:z lf Bag :Z 2 > = Bag:z Q A Ordered:z Q 
where cr T : LIST (IN) X LIST (]N) LIST(]N). 

In Section 4.2.2 we derive a program called Merge satisfying this specification. 

5. Determine the guards. 

Ihe guard ~q is simply Length :x Q > 1 - the input condition on <t e . Negat- 
ing, we obtain q:x 4=> Length:x_< 1. It is easily shown that q is defined on all 
legal inputs. 

6. Construct the primitive operator. 

The primitive operator has specification 

h:x = z such that Length:x_<l =£> Bag :x = Bag :z A Orderediz 
where h: LIST (IN) -» LIST(]N). 

The identity operator Id is easily shown to satisfy this specification. 

7. Construct a new input condition. 

This step is skipped since an operator has been found which satisfies the 
specification h. 

8. Construction of the divide and conquer algorithm. 
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Hypotheses: 



1. Append :<x 1 /X 2 > = x Q 

2. Lengthtx^ = Length:x 0 div 2 

3. Length:x 2 = (1 + Length:xg) div 2 

4. Length:xQ > Lengthrx^ 

5. LengthiXg > Length:x 2 

6. Bagix^ = Bag :z^ 

7. Ordered :z^ 

8. Bag:x 2 = Bag :z 2 

9. Ordered :z 2 

Variables: {Zg,z^,z 2 } 

Goal 1: <Q> Bag:x Q = Bag:z 0 

R5 + hi 

<Q> Bag:Append:<x^,x 2 > = Bag:Zg 
R5 + L9 

<Q> Union:<Bag :x^,Bag :x 2 > = Bag :Zq 

R5 + h6, R5+h8 
<Q> Union: <Bag :z 1# Bag :z 2 > = Bag :z 0 
P2 

where Q is Ordered :z^ A Ordered :z 2 =£< Union: <Bag :z^, Bag :z 2 > = Bag :z Q 

Goal 2: -(Ordered^ A Ordered:z 2 =£> Ordered:Zg> Ordered:Zg 

P2 

Figure 19: Derivation of output conditions for Merge. 



Assembling the operators derived above we obtain the program 
Msortrx = if 

Length :x _< 1 x Q 

Length:x > 1 Merge* (Msort X Msort) • Listsplit:x 
fi 

The derived input condition on Msort is TRUE. 
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4.2.2 Synthesis of Merge 



In the previous section we derived the following specification for a compo- 
sition operator which will be called Merge. 

Merge: <Xq,x' q> = Zq such that Ordered:x Q A Ordered x' 0 =» 

Union: <Bag:Xg, Bag :x' q> = Bag :Z q A Ordered:Zg 
where Merge: LIST (W) X LIST ( IN ) LIST(IN). 

A divide and conquer algorithm for Merge is synthesized as follows. 

1. Determine sort set and signature. 

There is only one choice of recurrent type in both the input and output 
domains - namely LIST(]N). As before we obtain sort set S= {c,§} and signature 
£ of type <c§,§> from the algebra A = <{ ]N,LIST( ]N) } , {Cons}>. 

2. Determine the component problems. 

Let 



E = LIST(IN) X LIST(U) 

§ 

T =LIST(]N) 

§ 

J^:<Xq,x'q> 4=^ Ordered :xq A Ordered :x'q 

P^:«Xq,x'q>,Zq> 4=£> Union: <Bag:x 0 , Bag :x' q> = Bag :Zq A Ordered :z Q 
E c = A c = M 

t c = a c = jn 

again we find Id:E c T c so let 

J c :x 44> TRUE 
P c :<x,z> 4 =t> x = z 
£ c - Id. 

3. Determine a well-founded ordering on E^. 

Since E =LIST(]N) X L IST(]N) we can construct a well-founded ordering by 
§ 

seeking a mapping from LIST ( ]N ) X LIST ( ]N ) to U X The function product 

Length X Length suffices so we define 

<Xq,x'q>^-<x 1 ,x' 1 > iff Length X Length :<xg,x' 0 > > 2 Length X Length:<x 1 ,x' 1 > 
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where <i Q , i ’ Q > > 2 <i i' i 'l > iff or ^0 =i l A i'o^'l)* 



4. Construct E and T. 

For Merge we construct Op then a^. 

TE 4.1 Construct T. 

The composition operator has specification 

cr T :<b,z i > = Zq such that TRUE 
where a T : IN X LIST (IN) LIST(W) 

The primitive operator Cons can be shown to satisfy Op. 

TE 4.2 Construct E 

TE 4.2.1 Derive output specifications for cr E . 

Tb obtain output conditions for the decomposition operator we derive a 
{xQ,x' 0 ,a ,Xp,x' p} -precondition of 

V«x 0 ,x' 0 >,a,<x 1 ,x' 1 »€ (LIST(N) X LIST(N)) X JN X (LIST(W) X LIST(]N)) 
V<z Q ,b,z 1 >€LIST(]N) X IN X LIST ( ]N ) 

[a = b A Ordered:Xp A Orderedix'p A Union:<Bag:xp,Bag:x'p> = Bag:Zp A 
Ordered:Zp A Cbns:<b,Zp> = Zq Union: <Bag:xQ, Bag :x ' q> = Bag :Zq A Ordered :Zq]. 

The derivation in Figures 21a and 21b yields the precondition 

Ordered :xp A Ordered :x'-, =» 

Union: <Bag:xQ, Bag :x'q> = Add :<a. Union :<Bag:Xp, Bag :x'p» A a<;Bag:Xp A a_<Bag:x'p. 

TE 4.2.2 Cbnstruct E. 

The decomposition operator <r E has specification 

cr E : < x o ,x ' 0> = < a »< x i' x ' 1 » suc h that Ordered :xq A Ordered :x'q =$> 

Ordered:Xp A Ordered:x'p A Length X Length :<Xq,x' q> > 2 Length X Length:<Xp,x' p> 

A Union:<Bag:xQ,Bag:x'g> = Add:<a / Union:<Bag:x 1 ,Bag:x' 1 » A a£Bag:Xp A a_<Bag:x'p 
where a E : LIST (]N) X LIST (]N) -» IN X (LIST( W) X LIST( IN) ) . 
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Hypotheses 



Hypotheses : 


1 . 


0 ) 

li 

c r 




2. 


Ordered :x^ 




3. 


Ordered :x’ j 




4. 


Union :<Bag:x 2 »Bag :x’ 2 > = Bag^ 




5. 


Ordered :z^ 




6. 


Cons:<b,Z 2 > = z Q 


Variables: 


< x 0' 


x , 0/ a,x 1 ,x , 1 } 



Goal 1: <Q1> Union: <Bag:x Q , Bag :x' q> = Bag :z Q 

R5 + h6 

<Q1> Union:<Bag:xQ,Bag:x'Q> = Bag: Cons :<a,z^> 

R5 + L8 

<Q1> Union: <Bag:x Q , Bag :x'q> = Add :<a,Bag :z^> 

R5 + h4 

<Q1> Union:<Bag:xQ,Bag:x'Q> = Add:<a,Union:<Bag:x^,Bag:x'^» 

P2 

where 01 is 

Ordered^ A Ordered :x'j =£• Union:<Bag:xQ,Bag:x'Q> = Add:<a,Union:<Bag:x 2 ,Bag:x '2 
Figure 20a: Deriving output specification for the composition operator in Merge 
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Goal 2: 



<Q3> Ordered :Z q 
R 5 + h6 

<Q3> Ordered :Cons:<a,z 1 > 

7T'''''\R3 + L12, R1 




<Q3> a^Bagtz^ 

R5 + h4 

<Q3> a < Union:<Bag :Xj,Bag :x ' 

R3 + B4 



<TRUE> Ordered :z-, 



PI +h5 



<Q1> a^Bagix-^ 
P2 




<Q2> a^Bagzx'j 
P2 



where Q1 is Ordered jx^ A Ordered ix'^ =$ a^Bagix^, 
Q2 is Orderedix^ A Orderedix'^ =^a _< Bagix'^, 
and Q3 is Ordered :x^ A Ordered ix'^ =$ Q1 A Q2 



Figure 20b: Deriving output specification for the composition operator in Merge 



A simple conditional program called Decompose can be constructed satisfying 
this specification with derived input condition Xq ^ nil A x'g^nil 

Decompose :<Xq,x'q> — if 

Firstrxg <_First:x' 0 -» <First:Xg,<Rest:xg,x , g» 0 
First:xg >^First:x'g -> <First:x' g,<Xg,Rest:x' g» 
fi 

5. Determine the guard. 

The derived input condition on Decompose is 

x q ^ nil A x'g^nil 

thus we define q:<Xg,x'g> to be Xg = nil V x'g=nil. We can easily verify that 
q is defined for all pairs of input lists. 

6. Construct the primitive operator. 
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We create the specification 



h:<XQ,x' 0 > = z 0 such that Ordered :x Q A Ordered :x'q A (x Q =nil V x' 0 =nil) =» 

Union:<Bag:xQ,Bag:x'Q> = BagiZQ A OrderediZg 
where h: LIST ( ON ) X LIST (]N) -» LIST(]N). 

We treat the disjunctive input condition by splitting the specification into two 
cases : 



ho : < x o» x 'o> = z o suc ^ that Ordered :Xq A Ordered :x'g A Xg = nil => 
Union:<Bag:xQ,Bag:x'Q> = Bag:zg A Ordered :z Q 
where h Q : LIST (]N) X LIST (]N) -» LIST(IN) 

and 



h 'o :<x O' x 'o > = z O suc h that Ordered :Xg A Ordered :x’g A x'g=nil =» 
Union:<Bag:xQ,Bag:x'g> = Bag:Zg A Ordered:z Q 
where h' Q : LIST (IN) X LIST (]N) -» LIST(]N) 

and synthesizing separate programs for them. The selector functions 2 and 1 are 
easily shown to satisfy hg and h'g respectively. 

7. Create new input conditions. 

This step is skipped since operators have been derived which satisfy the 
specifications hg and h'g. 

8. Assembly of a divide and conquer algorithm. 

Putting together the operators derived above we obtain 

Merge :<Xg,x'g> = if 

Xg = nil -» X'g 0 

X'g = nil Xg D 

Xg^nil Ax'g^nil Cons* (Id X Merge) ’Decompose :<Xg,x'g> 
fi 

The derived input condition for Merge is TRUE. The complete Merge sort program 



- 80 - 



Msort:x — if 



Leng th : x _< 1 -> x Q 

Lengthtx > 1 -» Merge* (Msort X Msort) *Listsplit:x 
fi 

Merge:<x^»X2> = if 

= nil x 2 0 
x 2 = nil — ^ x^ D 

x^^nil A x 2 ^nil Cons* (Id X Merge) • Decompose .^xpX^ 
fi 

Decompose :<x 1 ,x 2 > = if 

Firstix^ < First:x 2 
Firstrx^ First:x 2 
fi 

Figure 21: Complete Merge Sort Algorithm. 



<First:x 1 ,<Rest:xpX 2 » 0 
<First:x 2 ,<XpRest:x 2 » 



4. 3 Synthesis of £ Quick Sort Algorithm 
4.3.1 Synthesis of Qsort 

The synthesis of a quicksort proceeds as with Mergesort diverging only at 
step 4. 



1,2,3. Determine a sort set, signature, component problems, and a well-founded 
ordering. 

As in Mergesort let 
S= {§}, 

£ be a simple S-sorted signature of type {§§,§}, 

= LIST(]N) , 

T = LIST( ]N ) , 

§ 

J :x TRUE, and 
§ 
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P :<x,z> <=*► Bag:x=Bag:z A Orderediz. 

§ 

Define x Q ^-x 1 iff Length:x Q > Lengthy. 

4. Construct decomposition and composition operators. 

In Msort we chose a simple decomposition operator, in Qsort we choose a 
simple composition operator. 

TE 4.1 Construct T. 

The composition operator has partial specification 

cr T :<z 1 ,z 2 > = Zq such that TRUE 
where cr T : LIST (U) X LIST (U) LIST(]N). 

The operator Append satisfies cr T with derived input condition TOUE. 

TE 4.2 Construct E. 

TE 4.2.1 Derive output conditions for erg. 

We seek a {xq, x i,x 2 } -precondition of 

V<x 0 ,x 1 ,x 2 >6LIST(]N) XLIST(]N) XLIST(IN) 

V<z 0 ,z 1 ,z 2 >6 LIST(]N) XLIST(]N) XLIST(]N) 

[Bagjx^ = Bagiz^ A Orderedrz^ A Bag:x 2 = Bag:z 2 A Ordered:z 2 A 
Append : <z^, z 2 > = Zq => Bag :X q = Bag :Zg A Orderedrzg] 

and in Figure 22 we derive 

Bag ;x i < Bag ;x 2 A Bag:x Q = Union:<Bag:x 1 ,Bag:x 2 >. 



TE 4.2.2 Construct <x E . 

Using previously derived results we construct by instantiation the specifi- 
cation 

CTgiXg = <x r x 2 > such that Length:Xg > Length:x^ A LengthiXg > Length:x 2 A 
Bag ;x i < Bag;x 2 A Bag :x 0 = Union: <Bag:x lf Bag :x 2 > 
where cr E :LIST(]N) H> LIST( ]N) X LIST( U) . 
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Hypotheses 



: hi. Bag :x^ = Bag :z^ 

h2. Ordered :z^ 
h3. Bag :X 2 = Bag :Z 2 
h4. Ordered:z 2 
h5. Append :<z 1 ,z 2 > = z Q 
Variables: {x 0 ,x lf x 2 } 

Goal 1: <Q1> Bag :x Q = Bag :z Q 

| R5 + h5 

<Q1> Bag:x Q = Bag: Append :<z lf z 2 > 

R5 + L9 

<Q1> Bag:x Q = Union : <Bag :z^, Bag :z 2 > 

R5 + hi, R5 + h3 
<Q1> Bag :Xq = Union:<Bag :x^/Bag :x 2 > 

P2 

where Q1 is Bag :X q = Union:<Bag :xi,Bag :x 2 > 



Goal 2: <Q2> Ordered :z Q 

R5 +h5 

<Q2> Ordered : Append :<z z 2 > 

f Rl, R1 

<TRUE> Ordered :z^ <Q2> Bag :z^ £ Bag :Z 2 <TRUE> Ordered :Z 2 

Pl+h2 | R5+hl, R5 + h3 Pl+h4 

<Q2> Bag:x^ £Bag:x 2 
P2 

where Q2 is Bag :x^ £ Bag :x 2 




Figure 22: Derivation of output conditions for the decomposition operator of Qsort 



This is an incomplete specification for the well-known partitioning operator of 
a quicksort. In the following section we synthesize an operator called Part 
satisfying this specification with derived input condition Length:x 0 >l. 

5. Determine the guard. 
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The guard ~q:Xg is simply the derived input condition on o-g so ~q:x Q 4=^ 
Length:x 0 > 1 and q:Xg 4=t> Length:Xg£l. It is easily verified that q is 

defined on all legal inputs. 

6. Construct the primitive operator. 

We construct specification 

h:xQ = Zg such that LengthiXg^l =¥ Bag :X q = Bag :Zg A Ordered :Z q 
where h:LIST(]N) LIST(U) 

and can easily show that Id satisfies it. 

7. Derive a new input condition. 

Since Id satisfies specification h this step is bypassed. 

8. Assemble divide and conquer algorithm. 

The operators constructed above compose to form the following program: 

Qsort:x = if 

Leng th : x <_ 1 -> x 0 

Length:x > 1 -> Append • (Qsort X Qsort) ‘Part :x 
fi 

The derived input condition on Qsort is TOUE. 

4. 3. 3 Synthesis of Partition 

In the previous section we derived the specification 

Partixg = <x^fX 2 > such that Length:xg > Lengthrx^ A LengthiXg > Length:x 2 A 
Bag :x i <. Bag:x 2 A Bag:xg = Union :<Bag:x^, Bag: x 2 > 
where Rart:LIST(W) -> LIST(W) X LIST(]N) . 

This specification can be transformed to a somewhat simpler form using the 
equivalence 

W 1 — w 2 ^ A i_<w 2 ] 

where w^ and w 2 are variables over BAGS(]N) and i varies over IN. Thus we get 
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Partl:x Q = <x lf X 2 > such that 3i[Bag:xj_<i A i£Bag:x 2 ] A 
Bag :x 0 = Union: <Bag:x 1 ,Bag:x 2 > A Length:x Q > Lengthy A Length:x Q > Length:x 2 
where Parti: LIST(]N) LIST ( IN ) X LIST ( IN ) . 

We can further transform this to 

Part2:x Q = <b,<z^,z 2 » such that Bag^jCb A b£Bag:z 2 A 
Bag :X q = Union: <Bag:z lf Bag :z 2 > A Length:x Q >Length:z 1 A Length :x Q >Length:z 2 
where Part2:LIST( IN) ]N X (LIST( U) X LIST( IN) ) 

Noting that 2*Part2:xQ satisfies the specification for Part we now synthesize a 
divide and conquer algorithm for Part2. 

1. Determine a sort set and signature. 

We choose LIST (IN) as recurrent type on the input and output domains and 
select the algebra A = <{ IN , LIST( IN ) } , {Cons} > to give us the sort set S={c,§} 
and signature £ of type <c§,§>. 

2. Determine the component problems. 

As in the synthesis of Select, Insert, and Merge let 

E = LIST( IN ) 

§ 

T = IN X (LIST(IN) X LIST (IN)) 

§ 

J :x TRUE 
§ 

P^ ♦ ^Xq , ^b , Kz ^ , z 2 ^^^ \ /■ 

Bag:z^£b A b^Bag:z 2 A 
Bag:x Q = Union:<Bag:Z 2 ,Bag:z 2 > A 
Length:x 0 >Length:z 1 A Length :x 0 >Length:z 2 . 

E c = IN , and 
T C =IN. 

We seek a function f s which maps E c to T Q and find Id, so 

J c :x <=> TRUE 
P c :<x,z> x = z. 



3. Determine a well-founded ordering on E^. 
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Again define Xq^-xj^ by Length:x Q > Length.-Xj. 



4. Construct E then T. 

ET 4.1 Construct E. 

We construct a simple decomposition operator according to the incomplete 
specification 



Og :x o = < a ,Xi> such that Length:x Q > Lengthrx^ 
where a E : LIST (]N) -» IN X LIST( ]N) . 

In the synthesis of Select we showed that [First, Rest] satisfies the same 
specification with derived input condition x Q ^nil. 

ET 4.2 Construct T. 

ET 4.2.1 Derive output conditions for Op. 

The composition operator's output conditions are found by deriving a 
{bfCj^ZpZ'pCQ/ZQ, z'q} -precondition of 

V<c 0 ,<z 0 ,z' 0 »€ H X (LIST(IN) X LIST(W)) 

V<b,<c 1 ,<z lf 2 ' 1 >»e H X (W X (LIST(W) X LIST(W))) 

V<x 0 ,a,x 1 >6 LIST(H) X LIST]N X LIST(W) 

[ [First, Rest] :Xq = <a,Xp> A Bagjz-^cp A c-^Bagsz'p A 

Bagtx^ = Union:<Bag:Zp,Bag:z'p> A Length:xp > Length:Zp A LengthtXp > 
Length :z' p A a=b 

=¥ Bag:z Q _<CQ A c 0 £Bag:z ' 0 A Bag:xg = Union :<Bag:z Q , Bag: z' 0 > A 
Lengthrxg > LengthrZg A Length:Xg > Length: z'q]. 



In Figures 24a and 24b we derive the precondition 



Bagrzp^Cp Acp^Bagrz'p => 1 + Length:Zp + Lengthrz ' p>Length:z 0 A 
1 + Length:z2 + Length:z'2>Length:z ' 0 A 
Add:<b,Union:<Bag:z2fBag:z'2» = Union:<Bag:zQ,Bag:z'g> A 
Bag:z 0 <c Q A c Q <Bag:z 0 . 



ET 4.2.2 Construct T. 
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Hypotheses: 


1. 


[First,Re s t] :X q = <a,x 1 > 




2. 


Bag :z^ < c^ 




3. 


c i .£ Bag : 2 ' j 




4. 


Bag^^ = Union: <Bag :z^, Bag :z ' 




5. 


Length :x^ > Length :z^ 




6. 


Lengthy > Length:z'i 




7. 


a = b 


Variables: 


{b,c 


l' Z ]/Z' 1 ,Cq,z 0 ,z' q} 



Goal 1: <Q1> Bag:x Q = Union :<Bag:z Q/ Bag: z' Q > 

R6 + L7 +hl 

<Q1> Bag:Cons:<a,X 2 > = Union:<Bag :z Q/ Bag :z 1 Q > 

R5 + L8 

<Q1> Add:<a,Bag:x 2 > = Union :<Bag:z Q , Bag :z'q> 

R5 + h4 

<Q1> Add : <b. Union XBagiZj^, Bag :z' 1 » = Union :<Bag:z Q , Bag :z' 0 > 

P2 

where Q1 is 

Bag:z^£c^ A Cj<B3g:z^ Add:<b,Union:<Bag:z^,Bag:z'^>> = Union:<Bag :Zg,Bag:z ’ q> 



Goal 2: <Q2> Bag:z 0 £c 0 

P2 

where Q2 is Bagiz^c-^ A c^^Bagiz'^ =£• Bag:ZQ_<c 0 



Goal 3: <Q3> c Q _<Bag:z' 0 

P2 

where Q3 is Bagrz-^^c^ A c^^Bagsz'^ =£• CQ^Bagsz'Q 



Figure 23a: Deriving output conditions for the decomposition operator in Part2. 



The specification for the composition operator <r T is 
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a T :<b,<c 1 ,<z 1 ,z' 1 >» = <c 0 ,<z 0/ z' 0 » such that Bagiz-^Cj A c-^Bagiz^ 

=> (Add:<b,Union:<Bag:z^,Bag:z 2 » = Union:<Bag:z 0 ,Bag:z' 0 > A 
1 + Length :z-^ + Length :z , 1 >Length:z Q A 
1 + Lengthiz^ + Length:z' j>Length:zQ A 
Bag:z 0 _<c 0 A c Q _<Bag:z 0 

where cr T : W X ( W X (LIST(M) X LIST(W))) WX(LIST(W)X LIST(W)) 

A simple conditional program can be derived satisfying this specification with 
derived input condition TOUE: 



Goal 4: <Q4> Length :x Q > Length :z Q 

R6 + L7 + hi 

<Q4> Length :Cons:<a,x^> > Length :z Q 

| R5 + L15 

<Q4> 1 + Length:x^ > LengthiZQ 

R6 + L19 +h4 

<Q4> 1 +Card: (Union:<Bag:z^,Bag:z'2>) > LengthiZQ 

| R5 + B5 

<Q4> 1 +Card:Bag:z 1 +Card:Bag:z' 1 > Length:z 0 

R5 + L18 

<Q4> 1 + Length :z^ + Length :z' ^ > Length:z Q 

P2 

where Q4 is Bagiz^^c^ A c j_<.Bag ; z'j. =# 1 + Lengthiz^ + Lengthiz'^ > Length:z Q 

Goal 5: <Q5> Length:xQ > Length:z ' 0 

(Derivation similar to the derivation of Goal 4) 
where Q5 is Bagiz^c^ A c j_ <_Bag :z ' j. =» 1 + Length:z^ + Lengthiz' ^ > Length:z' 0 

Figure 23b: Deriving output conditions for the decomposition operator in Part2. 
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Compose : <b, <c, <z, z '»> 



if 



b<c <c,Cons:<b,z>,z’> Q 
b>c -> <c,z,Cons:<b,z '» 



5. Determine the guard. 

We take as ~q the derived input condition x^nil of cr E , thus q:x <£=> 
x=nil. It is easily shown that q is defined on all legal inputs. 

6. Construct the primitive operator. 

We construct the specification 

h:x = <c,<z,z'» such that x = nil => Bag:z£c A c_<Bag:z' A 
Bag:x = Union :<Bag:z, Bag :z'> A Length:x > Length:Zi A Length:x > Lengthrz'-^ 

where h: LIST (W) LIST ( IN ) X LIST ( ]N ) . 



As in the synthesis of Select we can show that this specification is unsatisfi- 
able. 



7. Derive a new input condition. 

We form a new input condition (because of the unsatisf iablility of h) by 
simplifying 



(TRUE A x Q ^ nil) V (TRUE A x = nil A FALSE) 



to Xq X nil. 
synthesis. 



We let J :x n 
§ 0 



Xq X nil and return to step 4 in order to redo 



the 



4' Construct E and T. 

ET 4.1' Construct E. 

Ihe new specification for <x E is 

a E :x 0 = <a,x l > suc h that Xq X nil (x^^nil A Length :xQ>Length:x2) 
where cr E : LIST (IN) INXLIST(IN). 

Since the operator [First, Rest] satisfied the first specification for cr E it 
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seems reasonable to try it again. Proposition 4 is used to show that 
[First, Rest] satisfies cr E with derived input condition Rest:x/nil. 

ET 4.2' Construct T. 

This step is not affected by the introduction of a new input condition thus 
our previous synthesis of Compose can be used. 

5'. Determine the guards. 

This time the derived input condition on Og is Rest:x/nil so 
~q:x 4=^ Rest :x ^ nil and q:x 4=^ Rest:x = nil. 

It is easily verified that q is defined on all legal inputs. 

6'. Construct the primitive operator. 

The primitive operator has specification 

h:x = <c,<z,z'» such that Restsx = nil => Bag:z <c A c <Bag:z' A 
Bagtx = Union:<Bag:z,Bag:z’> A Length:x > Length:z A Lengthrx > Lengthrz' 
where h: LIST (IN) U X (LIST( W X LIST( ]N) ) 

and again we find this to be unsatisf iable. Thus we will need to find a new 
input condition and return to step 4. 

7'. Derive a new input condition. 

The new input condition is found by simplifying 

(x / nil A Rest:x^nil) V (x / nil A Rest:x=nil A FALSE) 

to Lengthrx > 1. We return again to step 4, letting J :x be Length:x > 1. 

§ 

4 " . Construct E and T. 

ET 4.1* * . Construct E. 

The new specification for a E is 
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a E :x O = <a,x l > such that Length ;x o > 1 =» (Lengthtx^ > 1 A Length:x 0 > Lengthrx-^) 

where <X E : LIST (IN) -> LIST( U) X LIST( IN) . 

As in step ET 4.1' we use Proposition 4 to match [First, Rest] with cr E and 
obtain derived input condition Length :xq > 2. 



This step is the same as ET 4.2 since the change in input condition does 
not affect the synthesis of <x T . 

5". Determine the guards. 

The derived input condition on <x E is Length :x 0 > 2 so 

_q:x <=> Length:x > 2 and q:x Length:x£2. 

Again we easily check that q is defined on all legal inputs. 

6''. Construct the primitive operator. 

The primitive operator has specification 

h:x = <c,<z,z'» such that Restrx^nil A Length:x£2 => Bag:z<c A 
c£Bag:z' A Bag:x = Union:<Bag:z,Bag:z'> A Lengthrx > Length:z A Length:x > Lengthrz' 
where h:LIST(]N) -» IN X LIST( IN ) X LIST( IN ) ) . 

A simple conditional program can be shown to satisfy this specification: 
h:x — if 

First:x <_ First*Rest:x <First:x, Cons:<First:x,nil>, Rest:x> D 
First:x First *Rest:x -» <First*Rest:x, Rest:x, Cons :<First:x, nil » 
fi . 

7''. Derive a new input condition. 

Since an operator was constructed which satisfies the specification for h 
we can bypass this step. 

8 * * - Assembly of the divide and conquer program. 

Putting together all of the operators derived above we obtain 
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Part:x s 2*Part2:x 



Part2:x — if 

Length:x_<2 -» h:x D 

Length:x > 2 Compose* (Id X Part2) * [First, Rest] :x 
fi. 

Length:x>l is the derived input condition on Part2. Ihe complete Quicksort pro- 



Qsortrx s if 

Length :x 1 -> x Q 

Length :x > 1 -> Append* (Qsort X Qsort) ‘Part :x 
fi 

Part:x = 2*Part2:x 
Part2:x — if 

Length:x<^2 -> h:x 0 

Lengthrx > 2 -» Compose* (Id X Part2) * [First, Rest] :x 
fi 

h:x = if 

First:x £ First*Rest:x -» <First:x f Cons:<First:x,nil>, Rest:x> 0 
Firstrx ^ First*Rest:x -» <First*Rest:x, Rest:x, Cons:<First:x,nil» 
fi 

Compose :<a,<b,z lf z 2 » = if 

a£b -» <b, Cons:<a,z 1 >, z 2 > 0 
a^>b <b, z^, Cons:<a / z 2 » 
fi 



Figure 24: Complete Quicksort Program 
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gram is listed in Figure 24. 



4.4 Other Sorting Algorithms . 

The sorting problem admits a variety of solutions. We have detailed the 
synthesis of four - a selection sort, insertion sort, mergesort, and quicksort. 
In this section we briefly indicate how some of the other kinds of sorting algo- 
rithms could be synthezised by our method. The exercise of deriving several 
sorting algorithms from a single specification has also been reported in 
[6,7,10]. 

Bubble Sort and Sinking Sort [13] 

Bubble sort can be viewed as a variation on selection sort in which the 
Select operation is performed by scanning through the input list interchanging 
consecutive elements which are out of order. The result is that the smallest 
element is deposited at one end of the list. The smallest element and the rest 
of the list are then easily obtained. The scan and interchange process is an 
instance of the general programming technique known as local search. Local 
search produces an output object by a sequence of small local modifications 
applied to an input object. In the Bubble/Selection operator the local modifi- 
cations are the interchanges of consecutive elements which are out of order. 
Thus to synthesize a bubblesort we would proceed as with Ssort except that we 
would construct a local search algorithm for Select rather than a simple divide 
and conquer algorithm. 

Similarly, sinking sorts may be viewed as variations on insertion sorts in 
which the specification for Insert has been satisfied by a local search algo- 
rithm. 

Heap Sort [13] 

The essence of heapsort is the heap data structure which allows fast opera- 
tors for insertion of arbitrary elements and selection of the smallest element 
on the heap. In a sense heapsort is like a selection sort in that it repeatedly 
obtains the smallest remaining element on the heap and adds it to the output. 
Heap sort is a classic instance of a greedy algorithm [1]. Thus, a design 
theory for simple greedy algorithms would enable the synthesis of heapsort. 
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5. Conclusion 



In this paper we have presented a framework for a top-down program syn- 
thesis system. The future success of systems of this kind depend on the 
development of design methods covering many classes of useful algorithms. We 
have taken a first step in that direction with design methods for simple divide 
and conquer algorithms and simple conditional programs. We are currently imple- 
menting a system which includes these design methods. 

The main distinguishing feature of our approach is the ability to decompose 
a problem into subproblems, each described by an automatically derived specifi- 
cation. This ability depends on knowledge of the structure of divide and con- 
quer algorithms (formulated in Theorem 1) and an engine for deriving precondi- 
tions. The need to precisely express the structure of divide and conquer algo- 
rithms has led to the notions of decomposition algebras, homomorphisms from 
decomposition algebras to composition algebras, and finally, the expression of 
the divide and conquer principle as a computational homomorphism. We are 
currently using these tools in exploring the structure of other classes of algo- 
rithms. A precondition engine is being implemented and currently can handle 
most of the derivations in this paper. We feel that the precondition problem 
will eventually take on a wider significance than its role in our system. Many 
of the tasks faced by computer science and AI may be usefully formulated in 
terms of theorem proving in a first-order logic. See for examples [9]. The 
greater flexibility and power of preconditions should enable us to greatly 
extend the set of tasks which can be precisely expressed and handled by deduc- 
tive means. 

Another distinguishing feature of our approach is the correct handling of 
incomplete specifications. A user can even omit input conditions knowing that 
(at a cost!) the system can derive input conditions for its product. As a 
result specifications are somewhat easier to create. Another advantage of 
incomplete specifications is that it makes it easier for the system to create 
specifications for subproblems. 
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Appendix 



We list below the data structure knowledge required by the examples of this 
paper. It is grouped according to data types and includes operator signatures, 
typical composition algebras, and known theorems. All variables are implicitly 
universally quantified. 

1. Natural Numbers (IN) 

Known Functions: 

+:1NX]N -> ]N 

W X N B 

Id : IN IN 

Known Theorems - let i, j, k vary over IN 
nl. i>0 <=» i + j > j 
n2. i + i >j =^> i > (j div 2) 

2. Lists of Natural Numbers (LIST (IN)) 

Known Functions: 

First: LIST ( IN ) IN + 

Rest: LIST ( IN) -> LIST(U) + 

Cons: ]N X LIST (U) -> LIST(IN) 

[First, Rest] : LIST (IN) W + X LIST( B ) + 

Listsplit:LIST(]N) LIST ( IN) X LIST ( ]N ) 

Append : LIST ( IN ) X LIST (IN) -> LIST(]N) 

Id : LIST ( IN ) -> LIST(IN) 

Length:LIST(]N) IN 

Ordered: LIST (IN) -> B 
Bag : LIST ( IN ) BAGS ( IN ) 

Algebras: < { LIST ( IN ) , ]N } , {Cons } > 

<{ LIST ( IN )},{ Append }> 
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Known Theorems: let x, y, z vary over LIST(]N), i vary over U, and w 

vary over BAGS(]N) 

LI. Defined :x 
L2. x=x 

L3. Defined :x A Defined :y <£=> Defined: (x = y) 

L4. x ^ nil Def ined ‘First :x 

L5. x^nil Defined ‘Rest:x 

L6. x ^ nil ^ Defined: [First, Rest] :x 

L7. [First, Rest] :x = <a,y> 4=» Cons:<a,y> = x 

L8. Bag 'Cons : <a, x> = Add: <a, Bag :x> 

L9. Bag ‘Append :<xj,X 2 > = Union:<Bag:x^,Bag:x 2 > 

L10. Defined ‘Listspl it :x 
Lll. Ordered :nil 

L12. a_<Bag:x A Ordered :x 4=*> Ordered • Cons: <a,x> 

L13. Ordered:xi A Ordered:x 2 A x i <. x 2 ^ Ordered *Append:<XpX 2 > 

L14. Length :nil = 0 

L15. 1 + Length :x = Length -Cons: <a,x> 

L16. x^nil => 1 + Length -Rest :x = Length :x 
L17. Length:x^ +Length:x 2 = Length ‘Append :<x lf x 2 > 

L18. Ca rd * Bag : x = Leng th : x 

L19. Bag : x = w =» Length :x = Card :w 

L20. Bag:nil=0 

3. Bags of Natural Numbers (BAGS(]N)) 

Known Functions: 

Add: M x BAGS (») BAGS ( IN ) 

Union : BAGS ( U ) X BAGS (]N) BAGS ( ]N ) 

< : D X BAGS ( IN ) B 

< :BAGS(]N) X BAGS(IN) B 

Card : BAGS ( ]N ) -» IN 

Algebras: < { BAGS ( ]N ) , ]N } , [Add } > 
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Known Theorems: let w vary over BAGS(IN) and i vary over IN 



Bl. w = w 
B2. i < ft 

B3. i ^ K. i 2 /\ i} < w i ^ K Add 
B4. i£w^ A i <. w 2 ^ i£ Union 
B5. Card • Union: <w^,w 2 > = Card: 
B6. Card * Add : <a, w> = 1 +Card:w 



:<i 2 ,w> 
:<w 1 ,w 2 > 
+ Card :w 2 
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